Pull to refresh
2
0.9

Специалист по теории типов USB-кабелей

Send message

и программировать чередование чисел, не важно натуральных, фибоначчи, факториалов или ещё чего, ни в энтерпрайзе не требуется ни в не энтерпрайзе.

При этом вы топите за тесты и ООП, хотя никто не видел никакого правильного ООП, и тесты нафиг не нужны ни энтерпрайзу, ни его пользователям. Плюс, все эти тесты тестируют 2+2 = 4, очень классно.

Вы таки будете смеяться, но в HEB, крупнейшем техасском (и одном из крупнейших американских) продуктовом ритейлере

As of 2022, the company had a total revenue of US$38.9 billion.[8] H-E-B ranked number 6 on Forbes' 2022 list of "America's Largest Private Companies".[9] The company also ranked number 3 on Forbes' 2024 list of "Customer Experience All-Stars."[10] H-E-B was named Retailer of the Year in 2010 by Progressive Grocer.[11] Supermarket News ranks H-E-B 13th on the list of "Top 75 North American Food Retailers" by sales.[12] Based on 2019 revenues, H-E-B is the 19th-largest retailer in the United States.

очень много бекенда на хаскеле.

Если про меня, я не жаловался на неясность trait'ов.

Неявность. НеяВность. Вы же рядом:

Rust, из-за наличия trait'ов и макросов может скрывать реализации алгоритмов, что для программистов на C не приемлемо.

И автомагию я не прелагал.

Вы это сделали только что, предложив компилятору автоматически делать move в зависимости от нетривиальных условий. В том числе, тихо и без предупреждений ломать код

std::string s { "я не могу общаться с ретардами, но приходится" };
doSmth(foo);
return s[0];

при изменении другой перегрузки. Это напрочь ломает всю идею типизации (обеспечение гарантий компилятором), когда наличие (и последующее удаление) doSmth(const std::string&)означает, что вы хотите именно копировать (или перемещать, неважно, но одно из поведений должно бытья вным) и потом перестать это делать.

Иными словами, если я удаляю эту перегрузку, то я хочу, чтобы компилятор меня ткнул носом в те места, где я на неё опирался, чтобы я подумал, что с этим делать (заменить на мув, переписать алгоритм, вернуть перегрузку). Если вы хотите, чтобы происходило что-нибудь, лишь бы происходило — пишите на джаваскрипте. Это ровно ваш [object Object], так что непонятно, зачем вы undefined is not a function.

Вы себе какой-то ошибочный образ в голове построили и пытаетесь с ним дискутировать. Мой вам совет. Выйдите на улицу, Подышите. Вам явно что-то мерещиться.

Перед тем, как раздавать советы, попробуйте научиться читать и не путать буквы, а затем — помнить, что вы же писали меньше суток назад. Задача со звёздочкой — продумывать, к чему приводят ваши предложения.

При наличии только одной функции с аргументом типом универсальной ссылки, перемещение могло выполняться автоматически.

А если у вас

void foo(auto&&);

то надо копировать или перемещать?

А если у вас

void foo(string& s, string&& f);
void foo(string&& s, string& f);

то что вы здесь будете копировать или перемещать в вызове, где оба аргумента не rvalue?

А если я не хочу перемещать, в конце концов, то что мне делать? Сделаете std::dontmove?

Предложения «ну давайте мувать автоматически, и копировать тоже автоматически, и вообще» может выдавать только человек, который не писал ничего сложнее хелловорлдов, и с std::move знаком по постам в блогах OTUS.

На уровне компилятора можно было добавить интринсинк, чтобы не использовать стандартную библиотеку.

Очень важная цель, мешающая на практике (нет).

Ура, наконец-то человек, с которым достоверно можно поговорить по существу!

либо заниматься выпасом котов, которые будут работать над этими обвязками.

Зачем этим выпасом заниматься? Они уже сами предложили свою помощь и кандидатуру.

У С есть одно неоспоримое приемущество перед Rust - этот язык, в целом, мёртв.

Что имеет некоторые последствия, к слову, по части привлечения новых разработчиков (Кристоф, к сожалению или к счастью, не вечен).

Шансов, что кто-то там что-то сделает deprecated, почти нет.

Ну как тебе сказать…

Кстати, отдельный лайк за то, чтобы defined-поведение делать undefined. Такого настолько явного в настолько тривиальном коде я даже в плюсах не припомню сходу.

Да, инструмент устарел на целую жизнь при этом, но зато никто не будет капать на мозг, что в этом сезоне мы код оформляем так, а кто не так, тот лох.

Я в очередной раз напомню, что девиз ядра для ядерных вещей — stable API is nonsense.

Вы проигнорировали некоторые мои вопросы, среди которых:

  1. Вы можете указать конкретный сценарий возникновения проблем, когда копипаста байндингов в драйвера даёт преимущество по сравнению с их централизацией в одной папочке (не обязательной для сборки ядра настолько же, насколько необязательны драйвера)?

  2. Где написано, что у Кристофа есть помощники-мейнтейнеры?

  3. Какие гарантии по времени отзыва даёт Кристоф и другие мейнтейнеры?

  4. Является ли принятое решение в ядре высеченным в граните на века?

  5. На каком языке написаны блобы прошивок, и как это мешает разработке?

так что я теперь буду в начале комментария их повторять и пополнять этот список.

Это неудобно в конкретной кодовой базе.

Я на всякий случай отмечу, что причина не становится технической от количества повторений, а конкретные сценарии вы так и не указали.

Этого было достаточно для отказа. Не можете с этим смириться - это ваши личные проблемы.

Достаточность этого для отказа в конкретном проекте просто показывает, что он окончательно скатился в клоунаду. Зачем по этому поводу испытывать вообще хоть какие-то эмоции, с которыми нужно было бы смиряться?

Сложно ему или сложно в принципе?

Сложно ему, очевидно. Или он у нас теперь демократически избранный лидер всех программистов, говорящий от их лица?

Он указывал не лично себя.

Ваша же цитата:

Maintaining multi-language projects is a pain I have no interest in dealing with.

(курсив мой)

Если я сейчас напишу «maintaining C projects is a pain I have no interest in dealing with», то это станет непреложной истиной по одному факту того, что я так написал?

Кристоф дал разъяснения

«Мне сложна но помощь не нужна»

и альтернативы

«Копипастите везде»

Вы не можете быть настолько непроходимо глупым, чтобы считать это альтернативой. Вы троллите.

Пользы в крупных проектах от Rust пока не видно, чтобы так громко заявлять.

— Польза от раста не показана.
— Результаты гугла по использованию раста в AOSP говорят об обратном.
— Nim и Zig тоже где-то используют, и что?
— Не в крупных проектах уровня AOSP или не в крупно-ответственных проектах уровня проксей клаудфлары.
— Польза раста в крупных проектах не показана.

Вы не уважаете собеседников, тролля их глупостью, поэтому я не буду уважать вас и спрошу прямо: вы идиот? Вы не можете поддерживать контекст больше, чем на 10 минут или две реплики? Или какая вообще может быть причина человеку высказывать нечётные реплики в диалоге выше?

проблема в том, что в подавляющем большинстве случаев это будет возврат указателя на объект стека

V не обязан быть на стеке. В какой момент на стеке оказывается шаблонный аргумент здесь?

template<int V>
auto foo() { ... }

foo<42>();

Я бы хотел посмотреть на ваш "иногда корректна" сценарий, потому что для меня это или говнокод с UB или без UB.

Я не помню точную формулировку в стандарте, но это UB с типами вроде intов и не UB с class non-type template parameters'ами (что и является C++20-фичей, и что вообще оправдывает существование этой функции — лично мне такое было нужно ровно для class NTTP).

Например, этот код компилируется (что означает, что там нет UB), а если раскомментировать, то нет:

template<auto V>
constexpr const auto& make_static()
{
  return V;
}

struct S
{
    int val;
};

constexpr int foo()
{
    constexpr auto& v1 = make_static<S { 42 }>();
    //constexpr auto& v2 = make_static<42>();
    return v1.val;
}

static_assert(foo() >= 0);

Не только в нём, а во множестве дополнительных элементов, которые являются частью стандартной библиотеки enable_if_t один из них. И для того, чтобы использовать их либо нужно использовать стандартную библиотеку

Ещё раз, sfinae плохо потому, что оно использует enable_if, который является частью стандартной библиотеки, которую надо нести целиком или реализовывать с нуля? Я правильно понял вашу «логическую» цепочку?

либо нести реализации с собой в код.

Ничего страшного, с кусками сишной библиотеки так и сделали.

С языком C со скрипом переходили на новый стандарт.

Кстати, интересно, зачем.

А тут вы прелагаете сразу с двух ног войди в C++20, который не во всех компаниях ещё используют.

Не во всех компаниях и C используют, и?

В ядро, где очень ревностно относятся к нововведениям

Ну вы ж сами показали, что C++20 полезнее и удобнее, чем, скажем, 17.

Тем, что должно быть явно вызвано.

А откуда компилятору знать, хотите вы тут явный мув или нет? Когда сможете в общем случае определять, нужно ли тут:

void sink(const MyObject&);
void sink(MyObject&&);

// ...

MyObject obj;
if (foo()) {
  sink(obj); // вот здеся move?
}
if (bar()) {
  otherSink(obj);
}

вызывать move или нет, расскажите, мне пожалуйста. А то я могу к этому свести проблему останова, мы с вами вместе опубликуем эпохальную статью, и вы увековечите своё имя. Идёт?

А когда неоднозначностей нет, то std::move вызывать не надо (например, implicit move в return, когда (N)RVO не срабатывает).

Даже если передаётся, как аргумент с типом универсальной ссылки.

Необязательность move в таких случаях делает код куда более чувствительным к рефакторингу, когда добавляется перегрузка функции, и код по-тихому ломается (давая худший перф на ровном месте).

Человек, который в одном комментарии жалуется на неявность трейтов раста и опасливость к изменениям, а в другом предлагающий подобную хрупкую автомагию — это, конечно, смешно.

И в примере вы забыли remove_reference_t развернуть, так как без него работать не будет. Это тоже часть стандартной библиотеки.

Когда говорят, что «X — однострочник», подразумевают, что остальные части языка всё ещё доступны. «X — однострочник на баше» не означает, что весь баш реализуется в одну строчку, или что используемые команды реализуются в одну строчку.

Вы проигнорировали некоторые мои вопросы, среди которых:

  1. Вы можете указать конкретный сценарий возникновения проблем, когда копипаста байндингов в драйвера даёт преимущество по сравнению с их централизацией в одной папочке (не обязательной для сборки ядра настолько же, насколько необязательны драйвера)?

  2. Где написано, что у Кристофа есть помощники-мейнтейнеры?

  3. Какие гарантии по времени отзыва даёт Кристоф и другие мейнтейнеры?

  4. Является ли принятое решение в ядре высеченным в граните на века?

  5. На каком языке написаны блобы прошивок, и как это мешает разработке?

так что я теперь буду в начале комментария их повторять и пополнять этот список.

Технические причины были указаны - удобство сопровождения.

Это станет техническими причинами тогда, когда будут указаны конкретные сценарии, при которых что-то будет неудобно. Потому что программистский фольклор и общий опыт показывает, что так, как предлагают растаманы, таки удобнее.

Про сложность Кристов не писал.

Писал, мол, что двуязычные кодовые базы сложно поддерживать.

Никто не критиковал вклад Гектора в код ядра.

Я не писал про критику. Вы отвечаете на какие-то собственные голоса в голове.

Кристоф дал альтернативное предложение

Которое осмысленно настолько же, насколько осмысленно предложение написать собственный форматтер кода для C++ вместо использования существующих, а иначе решить (и высечь на камне), что стиля кода нет никакого.

Он лишь написал, что «вера у него кончилась» (это цитата).

Это норм. Мы все во что-то верим — в благонамеренность тех, с кем взаимодействуем, как пример.

А они там должны быть?

Для того, чтобы это было ответом на моё «раст показывает свою пользу в крупных проектах» — да.

Ясно, понятно.

Не уверен, что вам что-либо ясно, потому что вы до сих пор воспринимаете предложение копипастить как адекватное контрпредложение.

И вы не указали, опять же, конкретные сценарии, показывающие профиты копипасты (что заставило меня добавить этот вопрос в список проигнорированных вами).

Что ж.

Безошибочный подбор правильных реализаций. Для того, чтобы избавиться от ошибочного подбора нужно строить много дополнительного не всегда очевидного с точки зрения понимания кода.

Что непонятно в enable_if_t?

Концепты исправляют ситуацию, но они в C++20.

Повод сразу использовать C++20!

Вы могли нормальный вопрос задать с самого начала, или, если вы знали, могли бы сразу дать на него ответ.

Мог, но имею право выражать их в форме риторических вопросов. А вы, если бы хотели донести свою точку зрения, могли бы ответить и на вопрос в такой форме.

Не однострочники. move как миниму на три строки. так как нужно избавиться от ссылочности перед этим.

template<typename T>
constexpr decltype(auto) move(T&& t) noexcept { return static_cast<std::remove_reference_t<T>&&>(t); }

Их не должно быть вообще в стандартной библиотеке, а должны быть на уровне языка.

Почему? Чем std::move выше хуже std::move-магического интринсика компилятора?

Есть ровно одна причина, но она настолько несущественна, что на неё можно забить.

Я привёл примеры.

Нет, вы привели только общие слова (которые с тем же успехом могут быть применены и к C).

Вы проигнорировали некоторые мои вопросы, среди которых:

  1. Где написано, что у Кристофа есть помощники-мейнтейнеры?

  2. Какие гарантии по времени отзыва даёт Кристоф и другие мейнтейнеры?

  3. Является ли принятое решение в ядре высеченным в граните на века?

  4. На каком языке написаны блобы прошивок, и как это мешает разработке?

так что я теперь буду в начале комментария их повторять и пополнять этот список.

А в чем неадекватность отказа со стороны Кристофа?

Например, в отсутствии технических причин? В предложении копипасты? В «мне сложно, но мне не нужны помощники»?

Неадекватными пока что только выглядят адепты Rust. Особенно Гектор Мартин.

Ух мерзавец какой неадекватный. Ему сказали, что результатам его труда тут не рады, и ему нужно сделать тройной тулуп с переворотом и сплясать, а он, инфантильный эмоционал, отказался тулупиться и плясать, а просто пошёл по своим делам. Ужас!

Который ушёл из мейнтейнеров из-за обиды на слова Торвальдса. Опять же чисто эмоциональный поступок. Не прагматика движет, а эмоции. Возможно даже инфантилизм.

Опять базарнобабковый дискурс пошёл.

Он это где-то написал, про обиду, про это всё? Или вы сами придумали?

Так и на Zig сейчас проекты пишут. На Nim, Odin. (любой другой новый красивый язык)

Сколько кода на Zig, Nim и Odin в AOSP? Сколько кода на Zig, Nim и Odin в клаудфларовских проксях?

Вы серьёзно не понимаете разницы, или просто упражняетесь в демагогии?

А зачем делать на каждый драйвер? Достаточно на несколько.

На каждый растовский драйвер, очевидно. Потому что без этих обвязок его невозможно написать.

Объяснить, доказать верность замены. Можно попробовать так пойти.

У этой лишней работы снова нет никаких технических причин.

Вы можете указать конкретный сценарий возникновения проблем, когда копипаста байндингов в драйвера даёт преимущество по сравнению с их централизацией в одной папочке (не обязательной для сборки ядра настолько же, насколько необязательны драйвера)?

если шаблон убрать то ничего не поменяется

Если шаблон убрать, то откуда взять V?

включая UB, который в данном случае практически гарантирован

Нет, эта функция иногда вполне корректна. А иногда — нет. Почему?

C не просто так стал языком ядра, а C++ не стал.

Например, по личным причинам — ну не нравится Торвальдсу язык, и всё тут. Или по легаси-причинам — просто потому, что в 91-м году с компиляторами и стандартом C++ было всё очень плохо.

И шаблоны отчасти были тому причиной.

Так в чём конкретно проблема со sfinae, можете сказать? Особенно чтоб в C++11 она усугубилась, как вы изначально говорили.

Сами задали выпрос. Если вещи очевидны, к чему тогда сам вопрос был.

Этот вопрос — риторический, и является ответом на ваш псевдоаргумент. Собственно, вопрос к этому ответу, и вы так и не пояснили, в чём конкретно проблемы.

Никак. В C нет семантики перемещения.

Всегда копируют, что ли? Ну вот заодно перемещать научатся. Видите, одни плюсы!

И вы можете запретить их добавлять? Не можете.

Не понял, почему не могу? Не принимаю патч, который добавляет что-то, точно так же, как не приму патч, который сегодня добавляет thrd_create.

Без костылей в виде std::move или std::forward из стандартной библиотеки семантика перемещения не работает.

Это вообще однострочники, их самому можно написать, в чём костыльность и в чём проблема?

Помимо ни есть ещё целая куча вещей.

Вы упорно избегаете конкретики, просто размахивая руками и высказывая общие тезисы.

Развивается. И библиотеки, конечно, и сам компилятор: например, относительно недавно линейные типы запилили, и планомерно-постепенно готовятся к зависимым типам (например, в ghc 9.12 запилили https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst ).

В том же где ему присылают патч с Rust кодом.

Нет, конечно. Достаточно дать им мейнтейнить соответствующую субдиректорию, и нет никаких проблем.

Он как мейнтейнер всей подсистемы отказал в патче считая, что это навредит сопровождению. Он имеет право на это.

Он имеет право даже отказать в патче, у которого первый символ каждой строки, начиная с 17-й, не складывается в фразу "c{hristoph is the greatest man on earth}". Вопрос в адекватности этих отказов, и мы обсуждаем именно его.

Он готов принять отдельный код на каждый драйвер, о чём написал, но не на всю систему в целом.

Исключительно потому, что отдельный код на каждый драйвер никто не будет делать, и он это понимает.

Это уже не важно. Ситуация уже произошла. Решение уже принято.

Высечено в граните прям?

Красивые лозунги в новостях многие умеют писать. Это ещё ничего не говорит.

Там кроме лозунгов ещё есть отчёты по дырявости кодовой базы на сях и плюсах и кодовой базы на расте в андроиде, например. И есть конкретные работающие продукты, которые выбрано делать на расте. Но это всё, конечно, мелочи и лозунги.

Они прописаны в списке мейнтейнеров.

Покажите, где в списке мейнтейнеров указано, что они конкретно помощники Кристофа.

Кристофу инкриминируют по сути неприязнь языка Rust.

Ну либо это, либо он царёк с ЧСВ, тут выбора нет.

В то время как сам Кристов писал, что у него нет негатива против языка.

Человек в одном комментарии пишет по смыслу «красивые лозунги мноиге умеют писать, поэтому неважно, что говорят» и «ну раз человек что-то написал, то это должно быть правдой, буду исходить из этого».

Спасибо вам за дискуссию, вы даёте повод орать в голосину просто в каждом комментарии.

А вас, как мне кажется, что-то задевает. Ведь Rust'у отказали, какая же несправедливость.

Про своё отношение к расту я уже писал. В данном же случае меня задевает только непроходимая, фанатичная глупость некоторых персонажей, защищающих такие решения и всерьёз предлагающих копипастить код для улучшения его поддерживаемости, или очень избирательно применяющих аргументы уровня «технология может быть опасной, она не всегда приводит к тому, что хочется». Но это скорее даже не задевание, а персональный челлендж такой — получится ли что-то донести человеку, который даже осилил открыть браузер и набрать там эйч эй би ар дот ком <enter>, поэтому обладает, наверное, какими-то когнитивными способностями, или не.

А как sfinae работает? Всегда так как задумано?

Это что за аргумент вообще такой? Какой мейнстримный ЯП всегда работает так, как задумано?

А как это поможет когда нужно и то, и то?

А как сишники сейчас справляются с тем, когда нужно и то, и то?

Кстати, на плюсах я могу сделать что-то в духе

// один раз, utility-класс
template<typename T>
struct ForceCopy
{
  const T& src;

  explicit ForceCopy(const T& s)
  : src { s }
  {}
};

// ...
Foo(const Foo&) = delete;
Foo(ForceCopy<Foo>) ...
Foo(Foo&& other) ...
operator=(const Foo&) = delete;
operator=(ForceCopy<Foo>) { ... }
operator=(Foo&&) { ... }

и использовать как

Foo foo = makeFoo();
//doSmthWithCopy(foo); ниработаит
doSmthWithCopy(ForceCopy { foo }); // работаит
doSmthWithCopy(std::move(foo)); // работаит
doSmthWithCopy(makeFoo()); // работаит
doSmthWithCopy(Foo { ... }); // работаит
//foo.bar(); линтер ругнётся на use-after-move

— всё предельно явно, грепабельно и типобезопасно (насколько это может быть безопасно для языков C-семейства).

И линтер действительно ругнётся, например, clang-tidy:

note: Object 'foo' is moved
   37 |     doSmthWithFoo(std::move(foo));
      |                   ^~~~~~~~~~~~~~
note: Method called on moved-from object 'foo'
   39 |     foo.bar();
      |     ^~~~~~~~~

Хотите сказать, что нет? Вы прям можете запретить не вызывать отдельные инклюды?

Да, конечно. Например, не имея этих инклюдов в путях компилятора в процессе сборки.

А что, запрещено документально?

Лол. Lmao even. В который раз убеждаюсь, что самые ярые фанаты сишки нихрена не знают о C, а самые ярые фанаты штабильности в ядре нихрена не знают ни о конкретном обсуждаемом ядре. Кекспертиза уровня опеннета.

Читайте https://kernelnewbies.org/FAQ/LibraryFunctionsInKernel . Потом можете погрепать исходники ядра на предмет упомянутой функции. Хотя не, у вас же их под рукой нет, так что я сделаю это за вас:

10:55:43 деанон@deadzxt /usr/src/linux % grep -Rw thrd_create | wc -l
0

знаете, что это значит?

Так он может выполнять работу. Свою. Ему чужая не нужна. А ему почему-то пытаются навязать другую работу.

В каком месте пытаются? Ему говорят, что обвязки готовы мейнтейнить другие люди.

Может быть. Время покажет.

Уже показало в опыте других компаний, от гугла с андроидом до cloudflare.

И не потому что они ему не нужны. У него уже есть помощники. Другие мейнтейнеры.

Где в процитированной вами фразе написано, что у него уже есть помощники?

Кстати, какие есть гарантии, что эти другие мейнтейнеры будут реагировать на проблемы в данный срок, как вы требовали ранее?

Вот его слова. Он писал не конкретно про байдинги rust кода.

Контекст дискуссии — растобайндинги. Вы говорите, что я не учитываю контекст высказываний, а потом сами берёте и выкидываете этот контекст.

А кодовая база, кстати, уже многоязычная. Проприетарные прошивки-блобы на каком языке написаны, по-вашему? Скрипты для системы сборки на чём написаны?

У него уже есть помощники.

В процитированной вами фразе этого нет.

Вот когда примут, тогда и приходите.

Говорить на серьёзных щщах «Я не буду принимать эти изменения в мой проект, пока эти изменения не покажут себя в моём проекте» не может даже сишник.

Не приняли код на Rust в одном месте. Пусть попытает счастье в другом.

Мне нравится, как легко вы распоряжаетесь чужим временем и усилиями при полном отсутствии технических причин для отказа.

А ещё спутником старости для некоторых является деменция.

Мои соболезнования, конечно, но это многое из ваших офигительных высказываний объясняет.

Шаблонов вполне досточно. SFINAE.

Было в C++03. C++11 добавило expression sfinae, но это вопрос юзабельности и упрощает метапрограммирование.

Впрочем, как шаблоны и sfinae влияют на стабильность ядра linux?

Копирование данных при неправильно перемещении.

operator=(const Foo&) = delete;
operator=(Foo&&) { ... }

Перемещение данных при неправильно копировании.

Это надо как-то отдельно постараться ещё.

Как там с use-after-free дела, кстати?

А такого нет в C++, либо вся библиотека в целом, либо своя собственная реализация на месте.

Кто сказал?

Напомню, кстати, что ядро написано не на стандартном C, а на диалекте. Апеллировать к отсутствию каких-то ограничений в стандарте плюсов — это снова интеллектуальная нечестность.

А я что-то не помню, чтобы для C запрещали использовать что-то из стандартной библиотеки.

Что, даже thrd_create можно в ядерном коде?

А исключение здесь где? То, что помощники могут помочь ещё не означает, что они нужны.

Если человек не может выполнять работу сам, значит, нужны.

В ту же логику можно принести - зачем усложнять там, где усложнения не требуется.

Если не требуется. А переход на rust — это вполне себе полезное изменение.

Так вы оригиналы посмотрите, чтобы не терять смысл заявлений. И для более детальной картины всех заявлений Кристофа. Потому что переводы не верны, а дёргать отдельные выражения без контекста - портить суть его слов и своего лично понимания.

Окей, покажите, где что выкинуто из контекста, и где переводы неверны. С отсылкой к оригиналу, конечно.

Так и Кристов не драйверы пишет. Он сопровождает одну из критических подсистем ядра.

А будет сопровождать вместе с кем-то ещё на пару, как ему и предлагают. Не вижу ничего страшного.

А где я вру? Мои слова описывают ситуацию, когда есть кодовая база двух языков, где один язык поддерживается одним, а другой - другим мейнтейнером. И для исправления ошибки кто-то в любом случае будет ждать выполнения работы другого. Вы же не знаете как будет, как будет и сколько это времени займёт. И я не знаю. И Кристоф не знает.

После принятия этих байндингов и покажут себя. Пока драйверов на расте немного, так что ничего страшного в этом нет.

А гарантий времени реакции нет ни у кого, даже у Кристофа. Или какое у него там SLA и что будет, если он его нарушит? Поэтому избирательно напирать на отсутствие гарантий от этих мейнтейнеров, когда их нет ни у кого — это признак либо глупости, либо интеллектуальной нечестности. Выбирайте сами.

Все кто находится в загончике чувствуют себя хорошо.

Конечно, ведь неславящих царька оттуда выкидывают.

Но это не подходит для критического, общественно важного ПО.

А C-макросы могут генерировать код? Я вроде думал, что они просто подменяют текст.

А с этим текстом потом что происходит, знаете?

И, кстати, макросы достаточно близки к тьюринг-полноте в теории (не отличаясь по выразительной силе от шаблонов, которые считаются тьюринг-полными несмотря на наличие зафиксированных в стандарте возможных ограничений на количество инстанциирований) и на практике (см. boost.preprocessor — там и циклы, и условия, и контейнеры, и много чего интересного можно сделать).

Это понимание приходит со временем.

Если вы хотите свести дискуссию к сверканию регалиями, то результат будет сильно не в вашу пользу. Я бы не рекомендовал.

Говорить, что копипаста помогает поддержке — это показывать, как говорится, что иногда старость приходит одна.

Все самые важные изменения пришли в C++11, а они с собой несут очень много специфичного поведения, которые для стабильности ядра linux, могут иметь отрицательный эффект.

Например?

Некоторые программисты например не знают, что семантика перемещения имеет свои особенности, и без костылей её не возможно применять. А костыли нужны. И часть таких костылей является частью стандартной библиотеки.

Например?

Ну, только чтобы это было вредно для ядра. Так-то костыли везде нужны, понятное дело.

А это значит, что нужно нести стандартную библиотеку языка C++ в ядро.

Только нужное для используемых вещей подмножество. std::thread для мув-семантики тащить не обязательно.

То есть, есть куча нюансов из-за которых просто так взять, и разрешить C++ в ядре нельзя

Этим аргументом и заботой о нюансах можно парализовать любую работу и любые изменения.

Замена конструкторов на возврат std::optional только добавит писанины, но не избавит вас от goto (возможно, в виде пачки вложенных if).

Зачем?

Maybeи Either … тьфу, optional и expected — это «линейные» монады, их можно разворачивать через co_await. Вполне можно писать код в духе

std::optional<int> getCount();

template<typename T>
std::optional<T*> allocateMem(int);

std::optional<Result> doStuff()
{
  const auto count = co_await getCount();
  const auto mem = co_await allocateMem<int>(count);
  const auto objects = co_await initialize(mem, count);
  co_return doSomethingWith(objects);
}

Information

Rating
1,777-th
Registered
Activity