Не только в нём, а во множестве дополнительных элементов, которые являются частью стандартной библиотеки 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 — однострочник на баше» не означает, что весь баш реализуется в одну строчку, или что используемые команды реализуются в одну строчку.
Вы проигнорировали некоторые мои вопросы, среди которых:
Вы можете указать конкретный сценарий возникновения проблем, когда копипаста байндингов в драйвера даёт преимущество по сравнению с их централизацией в одной папочке (не обязательной для сборки ядра настолько же, насколько необязательны драйвера)?
Где написано, что у Кристофа есть помощники-мейнтейнеры?
Какие гарантии по времени отзыва даёт Кристоф и другие мейнтейнеры?
Является ли принятое решение в ядре высеченным в граните на века?
На каком языке написаны блобы прошивок, и как это мешает разработке?
так что я теперь буду в начале комментария их повторять и пополнять этот список.
Технические причины были указаны - удобство сопровождения.
Это станет техническими причинами тогда, когда будут указаны конкретные сценарии, при которых что-то будет неудобно. Потому что программистский фольклор и общий опыт показывает, что так, как предлагают растаманы, таки удобнее.
Про сложность Кристов не писал.
Писал, мол, что двуязычные кодовые базы сложно поддерживать.
Никто не критиковал вклад Гектора в код ядра.
Я не писал про критику. Вы отвечаете на какие-то собственные голоса в голове.
Кристоф дал альтернативное предложение
Которое осмысленно настолько же, насколько осмысленно предложение написать собственный форматтер кода для C++ вместо использования существующих, а иначе решить (и высечь на камне), что стиля кода нет никакого.
Он лишь написал, что «вера у него кончилась» (это цитата).
Это норм. Мы все во что-то верим — в благонамеренность тех, с кем взаимодействуем, как пример.
А они там должны быть?
Для того, чтобы это было ответом на моё «раст показывает свою пользу в крупных проектах» — да.
Ясно, понятно.
Не уверен, что вам что-либо ясно, потому что вы до сих пор воспринимаете предложение копипастить как адекватное контрпредложение.
И вы не указали, опять же, конкретные сценарии, показывающие профиты копипасты (что заставило меня добавить этот вопрос в список проигнорированных вами).
Безошибочный подбор правильных реализаций. Для того, чтобы избавиться от ошибочного подбора нужно строить много дополнительного не всегда очевидного с точки зрения понимания кода.
Что непонятно в enable_if_t?
Концепты исправляют ситуацию, но они в C++20.
Повод сразу использовать C++20!
Вы могли нормальный вопрос задать с самого начала, или, если вы знали, могли бы сразу дать на него ответ.
Мог, но имею право выражать их в форме риторических вопросов. А вы, если бы хотели донести свою точку зрения, могли бы ответить и на вопрос в такой форме.
Не однострочники. move как миниму на три строки. так как нужно избавиться от ссылочности перед этим.
Вы проигнорировали некоторые мои вопросы, среди которых:
Где написано, что у Кристофа есть помощники-мейнтейнеры?
Какие гарантии по времени отзыва даёт Кристоф и другие мейнтейнеры?
Является ли принятое решение в ядре высеченным в граните на века?
На каком языке написаны блобы прошивок, и как это мешает разработке?
так что я теперь буду в начале комментария их повторять и пополнять этот список.
А в чем неадекватность отказа со стороны Кристофа?
Например, в отсутствии технических причин? В предложении копипасты? В «мне сложно, но мне не нужны помощники»?
Неадекватными пока что только выглядят адепты Rust. Особенно Гектор Мартин.
Ух мерзавец какой неадекватный. Ему сказали, что результатам его труда тут не рады, и ему нужно сделать тройной тулуп с переворотом и сплясать, а он, инфантильный эмоционал, отказался тулупиться и плясать, а просто пошёл по своим делам. Ужас!
Который ушёл из мейнтейнеров из-за обиды на слова Торвальдса. Опять же чисто эмоциональный поступок. Не прагматика движет, а эмоции. Возможно даже инфантилизм.
Опять базарнобабковый дискурс пошёл.
Он это где-то написал, про обиду, про это всё? Или вы сами придумали?
Так и на Zig сейчас проекты пишут. На Nim, Odin. (любой другой новый красивый язык)
Сколько кода на Zig, Nim и Odin в AOSP? Сколько кода на Zig, Nim и Odin в клаудфларовских проксях?
Вы серьёзно не понимаете разницы, или просто упражняетесь в демагогии?
А зачем делать на каждый драйвер? Достаточно на несколько.
На каждый растовский драйвер, очевидно. Потому что без этих обвязок его невозможно написать.
Объяснить, доказать верность замены. Можно попробовать так пойти.
У этой лишней работы снова нет никаких технических причин.
Вы можете указать конкретный сценарий возникновения проблем, когда копипаста байндингов в драйвера даёт преимущество по сравнению с их централизацией в одной папочке (не обязательной для сборки ядра настолько же, насколько необязательны драйвера)?
Например, по личным причинам — ну не нравится Торвальдсу язык, и всё тут. Или по легаси-причинам — просто потому, что в 91-м году с компиляторами и стандартом C++ было всё очень плохо.
И шаблоны отчасти были тому причиной.
Так в чём конкретно проблема со sfinae, можете сказать? Особенно чтоб в C++11 она усугубилась, как вы изначально говорили.
Сами задали выпрос. Если вещи очевидны, к чему тогда сам вопрос был.
Этот вопрос — риторический, и является ответом на ваш псевдоаргумент. Собственно, вопрос к этому ответу, и вы так и не пояснили, в чём конкретно проблемы.
Никак. В C нет семантики перемещения.
Всегда копируют, что ли? Ну вот заодно перемещать научатся. Видите, одни плюсы!
И вы можете запретить их добавлять? Не можете.
Не понял, почему не могу? Не принимаю патч, который добавляет что-то, точно так же, как не приму патч, который сегодня добавляет thrd_create.
Без костылей в виде std::move или std::forward из стандартной библиотеки семантика перемещения не работает.
Это вообще однострочники, их самому можно написать, в чём костыльность и в чём проблема?
Помимо ни есть ещё целая куча вещей.
Вы упорно избегаете конкретики, просто размахивая руками и высказывая общие тезисы.
Нет, конечно. Достаточно дать им мейнтейнить соответствующую субдиректорию, и нет никаких проблем.
Он как мейнтейнер всей подсистемы отказал в патче считая, что это навредит сопровождению. Он имеет право на это.
Он имеет право даже отказать в патче, у которого первый символ каждой строки, начиная с 17-й, не складывается в фразу "c{hristoph is the greatest man on earth}". Вопрос в адекватности этих отказов, и мы обсуждаем именно его.
Он готов принять отдельный код на каждый драйвер, о чём написал, но не на всю систему в целом.
Исключительно потому, что отдельный код на каждый драйвер никто не будет делать, и он это понимает.
Это уже не важно. Ситуация уже произошла. Решение уже принято.
Высечено в граните прям?
Красивые лозунги в новостях многие умеют писать. Это ещё ничего не говорит.
Там кроме лозунгов ещё есть отчёты по дырявости кодовой базы на сях и плюсах и кодовой базы на расте в андроиде, например. И есть конкретные работающие продукты, которые выбрано делать на расте. Но это всё, конечно, мелочи и лозунги.
Они прописаны в списке мейнтейнеров.
Покажите, где в списке мейнтейнеров указано, что они конкретно помощники Кристофа.
Кристофу инкриминируют по сути неприязнь языка Rust.
Ну либо это, либо он царёк с ЧСВ, тут выбора нет.
В то время как сам Кристов писал, что у него нет негатива против языка.
Человек в одном комментарии пишет по смыслу «красивые лозунги мноиге умеют писать, поэтому неважно, что говорят» и «ну раз человек что-то написал, то это должно быть правдой, буду исходить из этого».
Спасибо вам за дискуссию, вы даёте повод орать в голосину просто в каждом комментарии.
А вас, как мне кажется, что-то задевает. Ведь Rust'у отказали, какая же несправедливость.
Про своё отношение к расту я уже писал. В данном же случае меня задевает только непроходимая, фанатичная глупость некоторых персонажей, защищающих такие решения и всерьёз предлагающих копипастить код для улучшения его поддерживаемости, или очень избирательно применяющих аргументы уровня «технология может быть опасной, она не всегда приводит к тому, что хочется». Но это скорее даже не задевание, а персональный челлендж такой — получится ли что-то донести человеку, который даже осилил открыть браузер и набрать там эйч эй би ар дот ком <enter>, поэтому обладает, наверное, какими-то когнитивными способностями, или не.
— всё предельно явно, грепабельно и типобезопасно (насколько это может быть безопасно для языков 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, а самые ярые фанаты штабильности в ядре нихрена не знают ни о конкретном обсуждаемом ядре. Кекспертиза уровня опеннета.
А такого нет в C++, либо вся библиотека в целом, либо своя собственная реализация на месте.
Кто сказал?
Напомню, кстати, что ядро написано не на стандартном C, а на диалекте. Апеллировать к отсутствию каких-то ограничений в стандарте плюсов — это снова интеллектуальная нечестность.
А я что-то не помню, чтобы для C запрещали использовать что-то из стандартной библиотеки.
А исключение здесь где? То, что помощники могут помочь ещё не означает, что они нужны.
Если человек не может выполнять работу сам, значит, нужны.
В ту же логику можно принести - зачем усложнять там, где усложнения не требуется.
Если не требуется. А переход на rust — это вполне себе полезное изменение.
Так вы оригиналы посмотрите, чтобы не терять смысл заявлений. И для более детальной картины всех заявлений Кристофа. Потому что переводы не верны, а дёргать отдельные выражения без контекста - портить суть его слов и своего лично понимания.
Окей, покажите, где что выкинуто из контекста, и где переводы неверны. С отсылкой к оригиналу, конечно.
Так и Кристов не драйверы пишет. Он сопровождает одну из критических подсистем ядра.
А будет сопровождать вместе с кем-то ещё на пару, как ему и предлагают. Не вижу ничего страшного.
А где я вру? Мои слова описывают ситуацию, когда есть кодовая база двух языков, где один язык поддерживается одним, а другой - другим мейнтейнером. И для исправления ошибки кто-то в любом случае будет ждать выполнения работы другого. Вы же не знаете как будет, как будет и сколько это времени займёт. И я не знаю. И Кристоф не знает.
После принятия этих байндингов и покажут себя. Пока драйверов на расте немного, так что ничего страшного в этом нет.
А гарантий времени реакции нет ни у кого, даже у Кристофа. Или какое у него там SLA и что будет, если он его нарушит? Поэтому избирательно напирать на отсутствие гарантий от этих мейнтейнеров, когда их нет ни у кого — это признак либо глупости, либо интеллектуальной нечестности. Выбирайте сами.
Все кто находится в загончике чувствуют себя хорошо.
Конечно, ведь неславящих царька оттуда выкидывают.
Но это не подходит для критического, общественно важного ПО.
А C-макросы могут генерировать код? Я вроде думал, что они просто подменяют текст.
А с этим текстом потом что происходит, знаете?
И, кстати, макросы достаточно близки к тьюринг-полноте в теории (не отличаясь по выразительной силе от шаблонов, которые считаются тьюринг-полными несмотря на наличие зафиксированных в стандарте возможных ограничений на количество инстанциирований) и на практике (см. boost.preprocessor — там и циклы, и условия, и контейнеры, и много чего интересного можно сделать).
Это понимание приходит со временем.
Если вы хотите свести дискуссию к сверканию регалиями, то результат будет сильно не в вашу пользу. Я бы не рекомендовал.
Говорить, что копипаста помогает поддержке — это показывать, как говорится, что иногда старость приходит одна.
Все самые важные изменения пришли в C++11, а они с собой несут очень много специфичного поведения, которые для стабильности ядра linux, могут иметь отрицательный эффект.
Например?
Некоторые программисты например не знают, что семантика перемещения имеет свои особенности, и без костылей её не возможно применять. А костыли нужны. И часть таких костылей является частью стандартной библиотеки.
Например?
Ну, только чтобы это было вредно для ядра. Так-то костыли везде нужны, понятное дело.
А это значит, что нужно нести стандартную библиотеку языка C++ в ядро.
Только нужное для используемых вещей подмножество. std::thread для мув-семантики тащить не обязательно.
То есть, есть куча нюансов из-за которых просто так взять, и разрешить C++ в ядре нельзя
Этим аргументом и заботой о нюансах можно парализовать любую работу и любые изменения.
Потому что если бы было норм самому, то не было бы «слишком сложно». А если слишком сложно, то помощники не помешают.
Я прямо чувствую себя неудобно, объясняя базовые логические выводы.
Даже больше, оба ваших перевода неверны.
Я взял переводы по ссылке товарища выше. Конечно, понятное дело, переводы верны, когда надо опровергнуть исходную статью, и переводы неверны, когда из них следуют неприятные для вас вещи.
Как собственно все неравнодушные адепты Rust'а в пабликах, как только переписка всплыла в новостях.
Я не знаю раст, не хочу его знать, и в мои планы не входит его изучение. Попробуйте адхом ещё раз.
Единственная верная суть в этом, что поддержка большой кодовой базы - это не биндинги написать.
Ага. А ещё поддержка большой кодовой базы — это не драйвер написать. И не бинарный блоб для amd влить. И что это говорит о всех тех людях, которые этим занимаются?
Не даром сам Торвальдс дал комментарий.
Ух! Сам Яжефинн Торвальдс!
Суть которого сводится к тому, что это не Rust плохой, а программисты на Rust плохие. Плохие для ядра linux. Им нужно меняться. Это был для них по сути совет. Как мальчик, которого бросают в воду, чтобы он научился плавать, не может изменить физику воды.
Дискурс уровня базара (не в смысле того, что противопоставляется Собору Рэймондом, о котором я говорил выше, а в смыле базарных бабок).
Это как раз показывает ваше непонимание. В ядре linux никто не будет ждать, что за дело возьмётся энтузиаст своего языка. Сломалось? Нужно чинить сразу.
Вы снова врёте: ждать не нужно, потому что люди вполне себе готовы взять на себя обязательства по мейнтейнерству.
А лучше вообще не ломать. Отсюда эта неприязнь нововведений. Которая оправдана.
Да, в ядре линукса же ничего никогда не вводят (даже когда уже что-то работает, см. фолианты, скажем), не ломают, и так далее.
Ядро linux - критическое ПО.
Для этого есть LTS-релизы.
Вы думаете только один Кристоф работает над DMA? Он там далеко не один.
Конечно. Царёк в загончике тоже не один. Но царёк опирается на безапелляционный авторитет у прочих членов загончика, который в linux kernel пока ещё хотя бы на словах следует меритократическим принципам.
А что они скрывают? Реализация остаётся реализацией внутри своего же отдельного блока кода, и даже единицы трансляции.
Нет, конечно. Если бы это было так, то у вас все функции были бы в одной единице трансляции, в одном большом таком .c-файле, а это, очевидно, не так.
Вы точно понимаете, о чём пишете, или просто какие-то умно звучащие слова накидываете?
Если трейт это ещё более менее определённая штука, то макрос может быть вообще чем угодно.
Что, в ядре линукса и сишные макросы уже запретили?
Если было изменение в обвязке, то просто так откатить ей не просто, так как все драйвера будут задеты изменениями, в отличии от изменений отдельного драйвера.
Казалось бы, сишник с его #include должен понимать, что нет никакой разницы вообще с точки зрения влияния изменений между #include "foo.h" и копированием содержимого foo.h на место инклюда. У меня таки начинают закрадываться некоторые подозрения.
Дело до того, что разговор с них начался, наверное? Вон какой исходный тезис был (самую важную часть выделил жирным):
Это абсолютно необходимо для программирования (не только на ассемблере) и оно обязательно входит в курс обучения в университете. Все кто заканчивал какое-то программирование этого проходили.
Реальный-то язык современного десктопного процессора, в который компилируется x86-64, закрыт и, видимо, сильно разный для AMD/Intel.
Лол, он сильно разный даже просто для разных поколений Intel. Мой любимый пример — разное поведение по зависимостям между 128- и 256-битными версиями simd-регистров в зависимости от конкретного поколения микроархитектуры интелов (где-то vzeroupper надо делать, чтобы OOO нормально работало, где-то — нет).
Ещё раз, sfinae плохо потому, что оно использует
enable_if, который является частью стандартной библиотеки, которую надо нести целиком или реализовывать с нуля? Я правильно понял вашу «логическую» цепочку?Ничего страшного, с кусками сишной библиотеки так и сделали.
Кстати, интересно, зачем.
Не во всех компаниях и C используют, и?
Ну вы ж сами показали, что C++20 полезнее и удобнее, чем, скажем, 17.
А откуда компилятору знать, хотите вы тут явный мув или нет? Когда сможете в общем случае определять, нужно ли тут:
вызывать
moveили нет, расскажите, мне пожалуйста. А то я могу к этому свести проблему останова, мы с вами вместе опубликуем эпохальную статью, и вы увековечите своё имя. Идёт?А когда неоднозначностей нет, то
std::moveвызывать не надо (например, implicit move в return, когда (N)RVO не срабатывает).Необязательность
moveв таких случаях делает код куда более чувствительным к рефакторингу, когда добавляется перегрузка функции, и код по-тихому ломается (давая худший перф на ровном месте).Человек, который в одном комментарии жалуется на неявность трейтов раста и опасливость к изменениям, а в другом предлагающий подобную хрупкую автомагию — это, конечно, смешно.
Когда говорят, что «X — однострочник», подразумевают, что остальные части языка всё ещё доступны. «X — однострочник на баше» не означает, что весь баш реализуется в одну строчку, или что используемые команды реализуются в одну строчку.
Вы проигнорировали некоторые мои вопросы, среди которых:
Вы можете указать конкретный сценарий возникновения проблем, когда копипаста байндингов в драйвера даёт преимущество по сравнению с их централизацией в одной папочке (не обязательной для сборки ядра настолько же, насколько необязательны драйвера)?
Где написано, что у Кристофа есть помощники-мейнтейнеры?
Какие гарантии по времени отзыва даёт Кристоф и другие мейнтейнеры?
Является ли принятое решение в ядре высеченным в граните на века?
На каком языке написаны блобы прошивок, и как это мешает разработке?
так что я теперь буду в начале комментария их повторять и пополнять этот список.
Это станет техническими причинами тогда, когда будут указаны конкретные сценарии, при которых что-то будет неудобно. Потому что программистский фольклор и общий опыт показывает, что так, как предлагают растаманы, таки удобнее.
Писал, мол, что двуязычные кодовые базы сложно поддерживать.
Я не писал про критику. Вы отвечаете на какие-то собственные голоса в голове.
Которое осмысленно настолько же, насколько осмысленно предложение написать собственный форматтер кода для C++ вместо использования существующих, а иначе решить (и высечь на камне), что стиля кода нет никакого.
Это норм. Мы все во что-то верим — в благонамеренность тех, с кем взаимодействуем, как пример.
Для того, чтобы это было ответом на моё «раст показывает свою пользу в крупных проектах» — да.
Не уверен, что вам что-либо ясно, потому что вы до сих пор воспринимаете предложение копипастить как адекватное контрпредложение.
И вы не указали, опять же, конкретные сценарии, показывающие профиты копипасты (что заставило меня добавить этот вопрос в список проигнорированных вами).
Что ж.
Что непонятно в enable_if_t?
Повод сразу использовать C++20!
Мог, но имею право выражать их в форме риторических вопросов. А вы, если бы хотели донести свою точку зрения, могли бы ответить и на вопрос в такой форме.
Почему? Чем std::move выше хуже std::move-магического интринсика компилятора?
Есть ровно одна причина, но она настолько несущественна, что на неё можно забить.
Нет, вы привели только общие слова (которые с тем же успехом могут быть применены и к C).
Вы проигнорировали некоторые мои вопросы, среди которых:
Где написано, что у Кристофа есть помощники-мейнтейнеры?
Какие гарантии по времени отзыва даёт Кристоф и другие мейнтейнеры?
Является ли принятое решение в ядре высеченным в граните на века?
На каком языке написаны блобы прошивок, и как это мешает разработке?
так что я теперь буду в начале комментария их повторять и пополнять этот список.
Например, в отсутствии технических причин? В предложении копипасты? В «мне сложно, но мне не нужны помощники»?
Ух мерзавец какой неадекватный. Ему сказали, что результатам его труда тут не рады, и ему нужно сделать тройной тулуп с переворотом и сплясать, а он, инфантильный эмоционал, отказался тулупиться и плясать, а просто пошёл по своим делам. Ужас!
Опять базарнобабковый дискурс пошёл.
Он это где-то написал, про обиду, про это всё? Или вы сами придумали?
Сколько кода на Zig, Nim и Odin в AOSP? Сколько кода на Zig, Nim и Odin в клаудфларовских проксях?
Вы серьёзно не понимаете разницы, или просто упражняетесь в демагогии?
На каждый растовский драйвер, очевидно. Потому что без этих обвязок его невозможно написать.
У этой лишней работы снова нет никаких технических причин.
Вы можете указать конкретный сценарий возникновения проблем, когда копипаста байндингов в драйвера даёт преимущество по сравнению с их централизацией в одной папочке (не обязательной для сборки ядра настолько же, насколько необязательны драйвера)?
Если шаблон убрать, то откуда взять
V?Нет, эта функция иногда вполне корректна. А иногда — нет. Почему?
Например, по личным причинам — ну не нравится Торвальдсу язык, и всё тут. Или по легаси-причинам — просто потому, что в 91-м году с компиляторами и стандартом C++ было всё очень плохо.
Так в чём конкретно проблема со sfinae, можете сказать? Особенно чтоб в C++11 она усугубилась, как вы изначально говорили.
Этот вопрос — риторический, и является ответом на ваш псевдоаргумент. Собственно, вопрос к этому ответу, и вы так и не пояснили, в чём конкретно проблемы.
Всегда копируют, что ли? Ну вот заодно перемещать научатся. Видите, одни плюсы!
Не понял, почему не могу? Не принимаю патч, который добавляет что-то, точно так же, как не приму патч, который сегодня добавляет
thrd_create.Это вообще однострочники, их самому можно написать, в чём костыльность и в чём проблема?
Вы упорно избегаете конкретики, просто размахивая руками и высказывая общие тезисы.
Развивается. И библиотеки, конечно, и сам компилятор: например, относительно недавно линейные типы запилили, и планомерно-постепенно готовятся к зависимым типам (например, в ghc 9.12 запилили https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst ).
Нет, конечно. Достаточно дать им мейнтейнить соответствующую субдиректорию, и нет никаких проблем.
Он имеет право даже отказать в патче, у которого первый символ каждой строки, начиная с 17-й, не складывается в фразу "c{hristoph is the greatest man on earth}". Вопрос в адекватности этих отказов, и мы обсуждаем именно его.
Исключительно потому, что отдельный код на каждый драйвер никто не будет делать, и он это понимает.
Высечено в граните прям?
Там кроме лозунгов ещё есть отчёты по дырявости кодовой базы на сях и плюсах и кодовой базы на расте в андроиде, например. И есть конкретные работающие продукты, которые выбрано делать на расте. Но это всё, конечно, мелочи и лозунги.
Покажите, где в списке мейнтейнеров указано, что они конкретно помощники Кристофа.
Ну либо это, либо он царёк с ЧСВ, тут выбора нет.
Человек в одном комментарии пишет по смыслу «красивые лозунги мноиге умеют писать, поэтому неважно, что говорят» и «ну раз человек что-то написал, то это должно быть правдой, буду исходить из этого».
Спасибо вам за дискуссию, вы даёте повод орать в голосину просто в каждом комментарии.
Про своё отношение к расту я уже писал. В данном же случае меня задевает только непроходимая, фанатичная глупость некоторых персонажей, защищающих такие решения и всерьёз предлагающих копипастить код для улучшения его поддерживаемости, или очень избирательно применяющих аргументы уровня «технология может быть опасной, она не всегда приводит к тому, что хочется». Но это скорее даже не задевание, а персональный челлендж такой — получится ли что-то донести человеку, который даже осилил открыть браузер и набрать там эйч эй би ар дот ком <enter>, поэтому обладает, наверное, какими-то когнитивными способностями, или не.
Это что за аргумент вообще такой? Какой мейнстримный ЯП всегда работает так, как задумано?
А как сишники сейчас справляются с тем, когда нужно и то, и то?
Кстати, на плюсах я могу сделать что-то в духе
и использовать как
— всё предельно явно, грепабельно и типобезопасно (насколько это может быть безопасно для языков C-семейства).
И линтер действительно ругнётся, например, clang-tidy:
Да, конечно. Например, не имея этих инклюдов в путях компилятора в процессе сборки.
Лол. Lmao even. В который раз убеждаюсь, что самые ярые фанаты сишки нихрена не знают о C, а самые ярые фанаты штабильности в ядре нихрена не знают ни о конкретном обсуждаемом ядре. Кекспертиза уровня опеннета.
Читайте https://kernelnewbies.org/FAQ/LibraryFunctionsInKernel . Потом можете погрепать исходники ядра на предмет упомянутой функции. Хотя не, у вас же их под рукой нет, так что я сделаю это за вас:
знаете, что это значит?
В каком месте пытаются? Ему говорят, что обвязки готовы мейнтейнить другие люди.
Уже показало в опыте других компаний, от гугла с андроидом до cloudflare.
Где в процитированной вами фразе написано, что у него уже есть помощники?
Кстати, какие есть гарантии, что эти другие мейнтейнеры будут реагировать на проблемы в данный срок, как вы требовали ранее?
Контекст дискуссии — растобайндинги. Вы говорите, что я не учитываю контекст высказываний, а потом сами берёте и выкидываете этот контекст.
А кодовая база, кстати, уже многоязычная. Проприетарные прошивки-блобы на каком языке написаны, по-вашему? Скрипты для системы сборки на чём написаны?
В процитированной вами фразе этого нет.
Говорить на серьёзных щщах «Я не буду принимать эти изменения в мой проект, пока эти изменения не покажут себя в моём проекте» не может даже сишник.
Мне нравится, как легко вы распоряжаетесь чужим временем и усилиями при полном отсутствии технических причин для отказа.
Мои соболезнования, конечно, но это многое из ваших офигительных высказываний объясняет.
Было в C++03. C++11 добавило expression sfinae, но это вопрос юзабельности и упрощает метапрограммирование.
Впрочем, как шаблоны и sfinae влияют на стабильность ядра linux?
Это надо как-то отдельно постараться ещё.
Как там с use-after-free дела, кстати?
Кто сказал?
Напомню, кстати, что ядро написано не на стандартном C, а на диалекте. Апеллировать к отсутствию каких-то ограничений в стандарте плюсов — это снова интеллектуальная нечестность.
Что, даже
thrd_createможно в ядерном коде?Если человек не может выполнять работу сам, значит, нужны.
Если не требуется. А переход на rust — это вполне себе полезное изменение.
Окей, покажите, где что выкинуто из контекста, и где переводы неверны. С отсылкой к оригиналу, конечно.
А будет сопровождать вместе с кем-то ещё на пару, как ему и предлагают. Не вижу ничего страшного.
После принятия этих байндингов и покажут себя. Пока драйверов на расте немного, так что ничего страшного в этом нет.
А гарантий времени реакции нет ни у кого, даже у Кристофа. Или какое у него там SLA и что будет, если он его нарушит? Поэтому избирательно напирать на отсутствие гарантий от этих мейнтейнеров, когда их нет ни у кого — это признак либо глупости, либо интеллектуальной нечестности. Выбирайте сами.
Конечно, ведь неславящих царька оттуда выкидывают.
Но это не подходит для критического, общественно важного ПО.
А с этим текстом потом что происходит, знаете?
И, кстати, макросы достаточно близки к тьюринг-полноте в теории (не отличаясь по выразительной силе от шаблонов, которые считаются тьюринг-полными несмотря на наличие зафиксированных в стандарте возможных ограничений на количество инстанциирований) и на практике (см. boost.preprocessor — там и циклы, и условия, и контейнеры, и много чего интересного можно сделать).
Если вы хотите свести дискуссию к сверканию регалиями, то результат будет сильно не в вашу пользу. Я бы не рекомендовал.
Говорить, что копипаста помогает поддержке — это показывать, как говорится, что иногда старость приходит одна.
Например?
Например?
Ну, только чтобы это было вредно для ядра. Так-то костыли везде нужны, понятное дело.
Только нужное для используемых вещей подмножество.
std::threadдля мув-семантики тащить не обязательно.Этим аргументом и заботой о нюансах можно парализовать любую работу и любые изменения.
Зачем?
MaybeиEither… тьфу,optionalиexpected— это «линейные» монады, их можно разворачивать черезco_await. Вполне можно писать код в духеЧем какой-нибудь
any_ofилиfor_eachплох?Нет, early return тоже норм.
А если найду всю эту замечательную макросню и
void*вместо нормальных типов?Потому что если бы было норм самому, то не было бы «слишком сложно». А если слишком сложно, то помощники не помешают.
Я прямо чувствую себя неудобно, объясняя базовые логические выводы.
Я взял переводы по ссылке товарища выше. Конечно, понятное дело, переводы верны, когда надо опровергнуть исходную статью, и переводы неверны, когда из них следуют неприятные для вас вещи.
Я не знаю раст, не хочу его знать, и в мои планы не входит его изучение. Попробуйте адхом ещё раз.
Ага. А ещё поддержка большой кодовой базы — это не драйвер написать. И не бинарный блоб для amd влить. И что это говорит о всех тех людях, которые этим занимаются?
Ух! Сам Яжефинн Торвальдс!
Дискурс уровня базара (не в смысле того, что противопоставляется Собору Рэймондом, о котором я говорил выше, а в смыле базарных бабок).
Вы снова врёте: ждать не нужно, потому что люди вполне себе готовы взять на себя обязательства по мейнтейнерству.
Да, в ядре линукса же ничего никогда не вводят (даже когда уже что-то работает, см. фолианты, скажем), не ломают, и так далее.
Для этого есть LTS-релизы.
Конечно. Царёк в загончике тоже не один. Но царёк опирается на безапелляционный авторитет у прочих членов загончика, который в linux kernel пока ещё хотя бы на словах следует меритократическим принципам.
Нет, конечно. Если бы это было так, то у вас все функции были бы в одной единице трансляции, в одном большом таком .c-файле, а это, очевидно, не так.
Вы точно понимаете, о чём пишете, или просто какие-то умно звучащие слова накидываете?
Что, в ядре линукса и сишные макросы уже запретили?
Казалось бы, сишник с его #include должен понимать, что нет никакой разницы вообще с точки зрения влияния изменений между #include "foo.h" и копированием содержимого foo.h на место инклюда. У меня таки начинают закрадываться некоторые подозрения.
Лол.
Дело до того, что разговор с них начался, наверное? Вон какой исходный тезис был (самую важную часть выделил жирным):
Это ключевой вопрос, потому что разговор о реалистичности тех или иных сценариев развития всегда неявно подразумевают их оправданность.
Проститутки ассоциируются с криминалом, не более. Говорят, в развитых странах с легализованной проституцией этой стигмы меньше.
Да и все мы занимаемся проституцией, продавая свои мозги, по большому счёту.
Лол, он сильно разный даже просто для разных поколений Intel. Мой любимый пример — разное поведение по зависимостям между 128- и 256-битными версиями simd-регистров в зависимости от конкретного поколения микроархитектуры интелов (где-то vzeroupper надо делать, чтобы OOO нормально работало, где-то — нет).
И это естественным образом прокачивается при работе обычным программистом ровно в том объёме, который обычным программистам и нужен.
Работа мечты!