В списке рассылки разработчиков ядра Linux возобновилось начатое шесть лет назад обсуждение перспектив использования современного кода на C++ в ядре Linux, помимо нынешнего применения языка Си с ассемблерными вставками и продвижения языка Rust. Изначально тема разработки ядра на C++ была поднята в 2018 году инженером из Red Hat, который первого апреля в качестве шутки опубликовал набор из 45 патчей для использования шаблонов, наследуемых классов и перегрузки функций C++ в коде ядра...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60436
Пока с++ не осилит инициализацию структур, говорить о переносе кода безполезно, ибо сизифов труд.
О чем речь? С++ может инициализировать структуры
struct A {
int a;
int b;
};A a1{1, 2};
работает в C++20 (может и в более ранних версиях)
a1{1, 2};
Вот не надо подобного. Когда полей в структуре не один десяток, получим нечитаемый говнокод и хорошими шансами на вагон опечаток.
a1{.v1=1, .v2=2} - работает в с++, но частично. Давится на порядок полей, и к тому что считает константами.
И подобное с Си в С++ не переносится без правки исходника.
> a1{1, 2};
> Вот не надо подобного. Когда полей в структуре не один десяток, получим
> нечитаемый говнокод и хорошими шансами на вагон опечаток.И хотя это правда, стоит добавить: когда в структуре столько полей - мы знаем что программер/архитект где-то сказочно облажались. Когда у вас столько полей, линейным списком, вы что-то сделали не так. Что, даже вложенный struct не смогли? Или это и правда плоский список такого размера? Что бы это могло быть в легитимном виде, когда того кто это сделал не надо бы уволить с треском за вот это все?
Начнём с того, что вложенные структуры конкретно данную проблему не исправят, а только добавят скобочек в визуально случайных местах инициализации структуры.Продолжим тем, что глупо добавлять структуры только для того, чтобы уменьшить число полей в каждой из них. Это вам не Ява, где шаг вправо-шаг влево - и у вас сонаркуб заругается, что в структуре больше двух полей, давайте, разбивайте на несколько структур, даже если смысла в этом нет, просто первую половину полей в одну структуру, вторую половину - во вторую.
И закончим на соседней новости, где просто изменением порядка полей в большой структуре добились увеличения производительности на 40%. В случае со вложенными структурами эта оптимизация была бы где-то в диапазоне от "выглядит бредово" до "это невозможно".
> Начнём с того, что вложенные структуры конкретно данную проблему не исправят, а
> только добавят скобочек в визуально случайных местах инициализации структуры.Вообще-то сделают данные более структурированные - и - вот - менее подверженными тому классу ошибок. Если вы это не понимаете - что я там про архитектов то говорил? Вывалить более 9000 сущностей линейным списком не больно какая архитектура.
> Продолжим тем, что глупо добавлять структуры только для того, чтобы уменьшить число
> полей в каждой из них. Это вам не Ява, где шаг
> вправо-шаг влево - и у вас сонаркуб заругается,Ну так правильно заругается. Нефиг гамнокодить. Структуры с дохреналионом полей уж точно не признак мастерства архитекта и изящества архитектуры.
> что в структуре больше двух полей, давайте, разбивайте на несколько структур,
> даже если смысла в этом нет, просто первую половину полей в одну структуру, вторую
> половину - во вторую.Со своей стороны я буду считать что более ~десятка полей в структуре - "кодер был неадекватен и делал какую-то фигню или не смог в архитектуру, гамнякая в режиме питоняши".
> И закончим на соседней новости, где просто изменением порядка полей в большой
> структуре добились увеличения производительности на 40%.А вот там господа таки - понимают что делают - и структур с более 9000 полей не заводят. И вложенные структуры юзать не гнушаются. Такая ерунда.
> В случае со вложенными структурами эта оптимизация была бы где-то в диапазоне
> от "выглядит бредово" до "это невозможно".С чего бы это вдруг? А 1 из примеров - заменили struct на u32. Стало даже проще. На самом деле есть tradeoff между нуждами оптимизации кода и изящностью и логической консистентностью апи. Не всегдя изящное логичное апи хорошо маппится на конкрерику оптимизера вот тут. Тот кто не джун и уже умеет в архитектуру и управление проектом немного - понимает что нужен какой-то разумный баланс. Если у вас более 9000 полей в структуре, очевидно, это профачено.
>>Когда у вас столько полей... вы что-то сделали не так.Что значит мы? Это задачи такие. И не все делается в одиночку. Что требуется для работы с устройствами и протоколами.
А в итоге, иногда, строки в исходнике распухают за 400 символов. ;)
Отформатируешь, так будет каша, в которой не разобраться.
Впрочем, что где то плохо спроектировано я соглашусь. Матерюсь же. ;)
> Что значит мы? Это задачи такие.Ну да, вы такие особенные на всю планету, наверное.
> И не все делается в одиночку.
Значит общее управление проектом оставляло желать. То что факап по чуть другой линии не означает что это офигенная идея и так и надо было.
> Что требуется для работы с устройствами и протоколами.
> А в итоге, иногда, строки в исходнике распухают за 400 символов. ;)Типа, когда это УГ надо скроллить даже на здоровенном мониторе - намного понятнее и читабельнее? Более того - это нехило ограничений на конфиги тех кто в проекте будет копаться. В опенсорсе чревато тем что вам вообще патчей не пришлют, решив что скроллякать ваши простыни на вон том лаптопе - нафиг надо, лучше другой код взять, менее отшибленый.
> Отформатируешь, так будет каша, в которой не разобраться.ORLY? У меня другие идеи на этот счет. Сорри. В случае опенсорса, если я где-то такое встречу, я просто немедленно сотру это как непотребное, если есть замена, или жестко отрефакторю, если по другому совсем никак. Потому что такой гамнякинг для меня приемлимым не является.
> Впрочем, что где то плохо спроектировано я соглашусь. Матерюсь же. ;)
Ну дык, иногда бывает что ну вот оставляет желать, но это ж не пример как надо делать. А пример как делать НЕ надо. Чтобы другие потом не матерились на такой код.
> Пока с++ не осилит инициализацию структур, говорить о переносе кода безполезно, ибо
> сизифов труд.Эй, это даже в си работает?! Вы там что-то совсем тормоз не отпустили?
Черт, даже можно присваивать однотипные структуры. Одна из причин по которым gcc в freestanding надо memcpy - конечно же такое присвоение это вот оно будет.
В смысле, 'даже'? В плюсах эта фича полноценно появилась только в C++20, когда как в Си с C99https://en.cppreference.com/w/cpp/language/aggregate_initial...
a = {.x = 1, .y = 2};
Вот такой синтаксис завезли только в 20е плюсцы.
>
> a = {.x = 1, .y = 2};
>
> Вот такой синтаксис завезли только в 20е плюсцы.Ага. А если не в исходнике было не {.x = 1, .y = 2, ...}, а в другом порядке { .y = 2, .x = 1, ...}, то надо править исходник, иначе не скомпилирует.
Все правильно, ибо нефиг создавать ложное впечатление, есть же строгий порядок инициализации.
> нефиг создавать ложное впечатление, есть же строгий порядок инициализации.Если сам с нуля пишешь то обычно да, логичнее писать по порядку, но бывает используется препроцессор, когда изменяемую часть надо выделить, то порядок меняется.
И конечно уже существующие исходники.Не забываем, что инициализацию структур только только добавили. И еще недавно можно было для больших структур делать или нечитаемую портянку, и как дурак считать каждый раз элементы, что б что то исправить, или мешать с и c++ файлы в проекте.
Шаг в сторону улучшения есть, что хорошо, но пока полумеры.
>> нефиг создавать ложное впечатление, есть же строгий порядок инициализации.
> Если сам с нуля пишешь то обычно да, логичнее писать по порядку,
> но бывает используется препроцессор, когда изменяемую часть надо выделить, то порядок
> меняется.Все это прекрасно выделяется блоками комментариев. Не могу представить ситуации с перестановкой блоков инициализации, чтобы это выделить.
> И конечно уже существующие исходники.
В существующих исходниках ничего не поменяется. А если уж хочется их "освежить" подобной инциализацией, то можно же предварительный корректирующий коммит сделать.
> Не забываем, что инициализацию структур только только добавили. И еще недавно можно
> было для больших структур делать или нечитаемую портянку, и как дурак
> считать каждый раз элементы, что б что то исправить, или мешать
> с и c++ файлы в проекте.
> Шаг в сторону улучшения есть, что хорошо, но пока полумеры.Для сложных случаев всегда можно было каждый инициализатор сопровождать маленьким блочным комментарием с имененем инициализируемого члена класса. Больше забот, но в сопровождении уж насколько проще. Хотя если разобраться, что в комментарии написать /* id */, что так написать .id=0 - практически один фиг ведь по количеству символов.
> Все это прекрасно выделяется блоками комментариев.Да это ж это же костылизм. Впрочем, сейчас оно уже в прошлом.
> Не могу представить ситуации с перестановкой блоков инициализации
Да легко. Переставили в какой ни будь библиотеке параметры в структуре, и что теперь собирающийся под разные варианты исходник корежить, и делать несколько его вариантов. А в embedded это не редкость, и при сборке под разные платформы тоже.
И туда же, как писал выше, генерация макросами.
И так же, заполнение не всех полей балластом, когда их много.
>> Не могу представить ситуации с перестановкой блоков инициализации
> Да легко. Переставили в какой ни будь библиотеке параметры в структуре, и
> что теперь собирающийся под разные варианты исходник корежить, и делать несколько
> его вариантов. А в embedded это не редкость, и при сборке
> под разные платформы тоже.
> И туда же, как писал выше, генерация макросами.
> И так же, заполнение не всех полей балластом, когда их много.Ничего не понял про собирающего. Если у него были старые исходники, то у него все поля инициализировались в строгом порядке вообще без указания поля, например: a{0, 2, 3}. Даже если ему придет в голову самолично переключить стандарт компиляции на C++20, то этот же код соберется без проблем, по крайней мере в этой части.
Я сейчас почти не пишу драйверы, но когда то писал. Сейчас в основном под встраиваемые контроллеры пишу.
Принципиальная разница инициализации структур с Си,в том что это и занимает 0 тактов, в отличии от конструкторов, и более того не требует временных переменных, что облегчает автоматизацию генерации кода.
Вне ядра проблема "элегантно" решается мешаниной файлов C и C++ в одном проекте.
Каких то причин, кроме религиозных убеждений, доя подобной несовместимости, и подобных - нет. И в идеале было бы хорошо, если бы компилятор C++ был чуть более совместимым с С.О другой проблеме - совместемости вызовов.
Частичное решение - extern "C".
И напрашивается добавить аналогичное extern "CPP", как стандартизированный вариант для API и библиотек.
> Принципиальная разница инициализации структур с Си,в том что это и занимает 0 тактов,На самом деле очень зависит от. И может являть собой и memset или memcpy в определенных случаях. Одна из ключевых причин по которым gcc требует от freestanding memset и memcpy - операции с структурами. Если не предоставить вон то, билд фирмвари может отвалиться с ошибкой линковки в взявшемся "изниоткуда" вызове memcpy/memset.
> в отличии от конструкторов,
На сях можно вполне сравнимо:
typedef struct my_data_t {
uint32_t a;
uint16_t b;
uint8_t arr[10];
} my_data_t;my_data_t defaults(void) {
my_data_t ret;
ret.a = 10;
ret.b = 20;
ret.arr[5] = 42;
return ret;
}
...
my_data_t someting = defaults(); // constructor-like entity.
Нужно ли так делать - "on case by case basis" конечно же. Причины те же что и у плюсеров, т.е. вкатить в "начальные значения" что-то "активно вычисляемое" что не удалось оформить компилтайм выражениями. Скажем нечто вычисляемое в зависимости от runtime переменных.> и более того не требует временных переменных, что облегчает автоматизацию генерации кода.
Опять же - это все сильно зависит от того что и как сделает программер и не является универсальным неотъемлимым и безусловным свойством "си вообще".
Сишка забевен тем что в силу простоты, он - мультипарадигменный. Куда хотите, туда и вертите.
> И в идеале было бы хорошо, если бы компилятор C++ был чуть более совместимым с С.
Ну вот кстати да. Чтобы C был именно subset БЕЗ оговорок.
> И напрашивается добавить аналогичное extern "CPP", как стандартизированный вариант для
> API и библиотек.В конечном итоге хруст, а вроде еще D, и кто там еще умеющие вызывать плюсоту что-то такое и делают :))
Вы предлагаете в структуры напихать методов на все случаи?
Только описывать их придется в одном месте, а вызывать из другого. Ну удобно же, и читаемо. :)А подобную инициализацию в портянки переписывать? C++ это не переваривает.
test1("Test1", &(const rqtm_t){.base = 1000, .answer1 = 150, .reaction = 2000, .transfer = 0, .rw = 0 });
test1("Test2", &(const rqtm_t){.base = 500, .answer1 = 50, .reaction = 100, .transfer = 80, .rw = 32 });
..> В конечном итоге хруст, а вроде еще D, и кто там еще
Так, идея в поддержке Си - исходников, а не переписывании.
В С и С++ нет методов, не было никогда и не будет -- есть функции-члены.
> Вы предлагаете в структуры напихать методов на все случаи?Я лишь констатировал что на си можно делать весьма по разному - в том числе даже и фокус на манер конструктора, вот, отколоть. Иногда даже может иметь свой пойнт. Нужно ли делать именно так в конкретном случае - на усмотрение програмера.
> удобно же, и читаемо. :)
Ну извините, в сях в общем случае принято допустим typedef в одном месте а фактическую инициализацию все же в другом. Ну вот так получилось. Это не очень хорошо, и если совсем не нравится то решаемо, но со своими граблями взамен.
> А подобную инициализацию в портянки переписывать?
Я иногда что-то такое могу как макро заколотить кстати. Т.е. вон то было бы как-то типа
// name, ..., ... ... rw
TEST1("Test1", 1000, 150, 2000, 0, 0);
TEST1("Test2", 500, 50, 100, 80, 32);
...
и при этом кстати не так уж важно как TEST1 внутри сделано. Можно и C++ легко осчастливить если станет нужно.А если это что-то типа массива однотипной хни по смыслу то и массив можно скроить, да еще в виде когда нельзя его криво сделать.
Т.e. как-то типа
TESTS_START(whatever)
TEST1(...);
TEST1(...);
TESTS_END...при том так можно сделать парсер, фигарящий по массиву struct'ов от сих до сих, и что самое забавное - итерирование этого как массива - корректно работает. Даже на си. И да, при правильном подходе это и правда лишь пачка констант, вплоть до .rodata, в мк уйдет в флеху.
С другой стороны работать с ними будет "итератор", а заполнять - макрос. Сишка так то позволяет делать довольно странные вещи.
> C++ это не переваривает.
Если не ощибаюсь так только с C++20 можно.
>> В конечном итоге хруст, а вроде еще D, и кто там еще
> Так, идея в поддержке Си - исходников, а не переписывании.Я даже как бы согласен, но если мир не идеален - упс, да, и чего? В C++ есть и еще пара отличий. Скажем auto до недавних пор в сях означало совсем другое. В C23 кстати это поменяли. C23 вооб ще довольно интрузивная штука. Но боюсь что комитета не хватит исправить наиболее жирные бестолковости сей. Типа, вот, дурных базовых типов и UB.
> Принципиальная разница инициализации структур с Си,в том что это и занимает 0 тактов, в отличии от конструкторовА можно пример, чтобы это было так не только с -O0? Зачем компилятору вызывать конструктор, когда он может применить оптимизации?
Можно этот переделать: https://godbolt.org/z/Y4G554zdr
А, методы, определённые в теле класса, неявно помечены как inline. Если определения конструкторов вынести - новое условие уже будет "чтобы это было так не только с -O0/-O1".
> ... почти не пишу драйверы, но когда то писал. Сейчас в основном под встраиваемые контроллеры пишу.
> аналогичное extern "CPP",Пейсатель, CPP - это C PreProcessor, CXX - для плюсов )))
Про 0 тактов - constexpr ctor.
consteval
> Про 0 тактов - constexpr ctor.1. Да, я это использую.
Но не так и редко бывает на ровном месте и
constexpr variable must be initialized by a constant expression
Особенно во встраиваемом ПО,что по духу ближе к ядру, чем пользовательские приложения.2. После обкладывания constexpr всего и вся правда ведь исходник и красивей и читаемей?
Поэтому, использую не в всегда.
> constexpr variable must be initialized by a constant expressionНа сях для тактов вы тоже либо скроите эквивалентное по смыслу, либо это не 0 тактов получится. За 0 тактов только то что удалось в константу сколлапсить, для чего оно должно быть вычисляемо на этапе компила. Иначе фиг тебе, золотая рыбка.
constexpr и задумано для этого. Не спорю.
Но где то не применимо. Хотя в большинстве случаев и предпочтительнее и мощнее.Смысл пожеланий о ициализации, в том, что бы с++ компилятор переваривал исходники Си без их правки.
Это не тяжелое изменение. А переезд могло бы сильно облегчить.
> constexpr и задумано для этого. Не спорю.
> Но где то не применимо. Хотя в большинстве случаев и предпочтительнее и мощнее.Как бы плюсы мощнее сей. Но если повыпендриваться - то си можно основательно перекроить. Но не факт что нужно, ибо огорошивать посторонних кодеров экзотичным диалектом... не очень хорошая идея. Хотя о C++ ходит даже в общем то и не шутка что каждый програмер пишет на своем диалекте C++.
> Смысл пожеланий о ициализации, в том, что бы с++ компилятор переваривал исходники
> Си без их правки.На 100.0% это все же врядли получится. Скажем "register" в C++ нету. И auto означало нечто совсем другое до недавних пор. Хоть я и не понимаю чем им "register" так уж не угодил.
> Это не тяжелое изменение. А переезд могло бы сильно облегчить.
Вот конкретно там я тоже не понимаю почему вообще должно быть такое отличие.
> 2. После обкладывания constexpr всего и вся правда ведь исходник и красивей
> и читаемей?
> Поэтому, использую не в всегда.Красивее - нет, но оно и не всегда нужно, а когда и вовсе нужно убирать.
А что плохого в extern "C"? Очень часто используется.
> в отличии от конструкторовэто не совсем так. placement new в C++ может инициализировать объекты по адресу в буфер. и также возможны свои реализации аллокаторов
static char buffer[128];
new (buffer) Circle()
> new (buffer) Circle()Благодарю. Жаль что с constexpr оно только с c++20 только, а то в embedded в ходу компиляторы и постарее. Но, уже лучше.
> ибо сизифов трудЕсть же знатоки.
>> ибо сизифов труд
> Есть же знатоки.А что не так? Если ни какими опциями компилятора нельзя избежать правки рабочего исходника и внесения новых опечаток, то вполне мартышкин труд.
Строго говоря разница усматривается. Сизифов труд это бесконечное наказание, мартышкин труд - бесполезное развлечение.
>> Пока с++ не осилит инициализацию структурС++ поддерживает 25 способов инициализации, и это уже само по себе проблема)
В 20 сишную .fild_name=100 запилили.
Нельзя туда цпп. Ладно модули, только не ядро. Запаримся пересобирать же! Си собирается намного шустрее.
Там жалобы есть в том числе на макросы. А они вполне себе могут компилиться дольше, чем какие-нибудь шаблоны, решающие ту же задачу
>Там жалобы есть в том числе на макросы. А они вполне себе могут компилиться дольше, чем какие-нибудь шаблоны, решающие ту же задачуШТО?
Макросы, в отличие от шаблонов цпп, не обладают тьюринговой полнотой. Это шаблоны можно заставить компилироваться сколь угодно долго.
> не обладают тьюринговой полнотойНо остаётся совсем чуть-чуть до этого.
https://github.com/Hirrolot/metalang99
https://jadlevesque.github.io/PPMP-Iceberg/Я сделал на шаблонах довольно мощную штуку с объектным программированием на C.
И оно компилится действительно очень долго.
Кроме TCC, он быстр даже в этих шаблонах. Правда, чуть-чуть бажит.
> Я сделал на шаблонах довольно мощную штуку с объектным программированием на C.
> И оно компилится действительно очень долго.А я сделал себе верификацию ряда операций в компилтайме, скажем что я в 32 бит регистре не трогаю 35-й бит. Почти хруст получился. Даже не тормозит особо. В сабже кстати есть зачатки этого добра откуда я и содрал идею.
Хотя круче всего это в Zig сделано - там можно компил тайм предвычисления юзая стандартный синтаксис яп. Плюсы в этом смысле - убогие полумеры, ибо препроцессор с отдельным синтаксисом никуда не делся. А какой-нибудь constexpr знатный горбыль так то.
> Макросы, в отличие от шаблонов цпп, не обладают тьюринговой полнотой.
> Это шаблоны можно заставить компилироваться сколь угодно долго.Они ну вот буквально на грани :). Единственный лимит - рекурсия до 128, чтоли, уровней в GCC разрешена. Но с таким количеством рекурсии можно основательно позажигать.
> Это шаблоны можно заставить компилироваться сколь угодно долгоДа, можно. Но это рассуждение об экстремальных примерах. Но экстремальные примеры — скорее редкость. Дуплицирование кода от макросов способно замедлять компиляцию точно так же, как и шаблоны. И способно иногда замедлять её даже сильнее при решении аналогичных задач
Тормозящие шаблоны целиком типичная ситуация в 100% проектов. Программы на этом языке компилируются дольше всего.
Шаблоны это compile time. Ну и хрен с ними, сколько им компиляться. Главное, чтобы потом сгенерённый код быстро работал.
А ещё макросы не анализируются также хорошо как шаблоны через статический анализ.
Так пусть определятся для начала. Если rust можно, то почему плюсы нельзя?
А кто сказал, что раст можно? Пока что раст -- это для модулей, которые с ванилью собирать не обязательно
Это сказал Линус в интервью, что ожидается большее использование в базовых компонентах ядра.Те модули - это пока, проба пера.
Только в драйверах и может быть в файловых системах, и то если все хорошо пойдет.
Потому что плюсы слишком громоздкие, много неявного поведения, имеется наследование классов, шаблоны. Чудовище Франкенштейна самое настоящее. В ядре такое - недопустимо, лишнее усложнение не нужно, высока цена ошибкиРаст же, как и Си, - прост. Да, раст посложнее Си по части обучения, но проще плюсов, и он предоставляет множество гарантий безопасности, чего нет в плюсах
>гарантий безопасностиКакие тебе гарантии нужны? Средства в плюсах давно есть. А если у тебя генетическая склонность стрелять по своим ногам, то тут и раст не справится.
Средства, использования которых необязательны? Было бы в плюсах все хорошо с безопасностью, не было бы придумано столь много безопасных замен ему. Раст учит разработчиков с самого начала изучения следить за правильной работой с памятью, не давая некорректному коду скомпилироватьсяГоворят, что у Раста мнимая безопасность, потому что есть unsafe (который в случае ошибки при работе с памятью, укажет разработчику, куда стоит смотреть в первую очередь), но код на плюсах - весь unsafe
> шаблоны. Чудовище Франкенштейна самое настоящее. В ядре такое - недопустимоДавайте полюбуемся на простые _Generic-макросы в ядре. И вообще на макросы.
https://github.com/torvalds/linux/blob/052d534373b7ed33712a6...
https://github.com/torvalds/linux/blob/052d534373b7ed33712a6...
А сколько там модулей в стандартной библиотеке, которые меняются из версии в версию (просто как вот это всё дебажить потом на уязвимости, если ядро на C уже вселенского масштаба)
Даже в Gentoo завезли бинарное ядро.
Для истинных гентушков это ничкго не изменило.
Как будто только гента позволяет ядро пересобрать. В Void это делается ровно точно так же с конфигом ядра без всяких use флагов.
Так сборка ядра в Генте ничем не отличается от сборки в других Линуксах. Неиспользуются при этом флаги USE. Только вот линуксоиды ныне измельчали, не собирают себе ядра. А потом ноют, что им такое жирнючее положили в дистр.
Отличается же, в генте не нужно готовить всякий шлак вроде initrd и не нужно собирать всё ядро. В других линуксах всё же обычно дают возможность пересобрать всё и это очень долго, а ксатомизировать крайне геморно
> Отличается же, в генте не нужно готовить всякий шлак вроде initrd и
> не нужно собирать всё ядро. В других линуксах всё же обычно
> дают возможность пересобрать всё и это очень долго,Yolo! Я майнлайне кернель под дебианом собираю. В билдсистеме ядра даже есть генерация пакетов. Таргет "make bindeb-pkg" - и билдсистема сама скроит пакетик с кернелом в лучшем виде. И да, часть систем тоже взлетает без initrt. Хоть они и дебианы. Что в этом такого?
И уж конечно кастомизировать можно все что угодно. Билдится это - в зависимости от того что включено. Только билдить кернел для 1 тазика не совсем практично - для какого-то "класса железок" намного прагматичнее. Ибо майнтайнить зоопарк - затея весьма голимая. Особенно как локалхостов становится более десятка.
> а ксатомизировать крайне геморно
Я бы не назвал menuconfig чем-то ужасным. А вон там для референса дистровский конфиг есть например. И гемор - он в чем? И чего так уж упрощает в этом гента? Там самое сложное - это понимать что эти галочки реально делают. Гента в этом не поможет вообще никак :)
> А вон там для референса дистровский конфиг есть например. И гемор - он в чем?Тем, что этот конфиг слишком избыточный и проще начать всё делать с нуля. Сложность заключается в кол-ве телодвижений от начала процесса и до выкатки в бутовый конфиг за вычетом времени в menuconfig
> Тем, что этот конфиг слишком избыточный и проще начать всё делать с нуля.ИМХО где как. На десктопе я от дистровского конифига танцевал, таргетируя более-менее похожие на мой компы x86-64, без совсем редких вундервафель махрового энтерпрайза или винтажного добра редко встречающегося в x86-64.
Да, кернел жирнее и дольше билдится. Зато подымает 3 мои компа включая "альтернативные/бэкапные" и ноут. Без затрат времени на билдовку им уберкастома. Это осознанный tradeoff.
А например на ARM - я местами и от мелкого defconfig оттанцевал. Потому что вот там из дистрокернела вырезать ненужное можно и заманаться уже, если я таргетирую допустим пяток похожих железок на чипах одной фирмы и более - нифига.
> Сложность заключается в кол-ве телодвижений от начала процесса и до
> выкатки в бутовый конфиг за вычетом времени в menuconfigКогда тазиков оказывается не 1 а эн, начинает хотеться некоторого обобщения оных и урезания объема работ. Если у меня легион одноплатников - и я буду каждому кернел под микроскопом пилять - я тогда займусь только микро-оптимизациями, а на более полезные и интересные проекты времени не останется. И вот интеерсные проекты будут спущены в угоду 2% перфоманса. А оно того точно стоило? Эти 2% никто не заметит - и я уж точно не упирался в 2% перфоманса в задачах которые там были. Иначе я бы выбрал более мощную железку, для более разумных сроков проекта.
>Нельзя туда цпп. Ладно модули, только не ядро. Запаримся пересобирать же! Си собирается намного шустрее.Так разговоры давно идут об введений подмножеств - урезанной современной версии языка.С выкидыванием всякого хлама,там такого всего накопилось ......
Вообще удивительно как это еще собирается.
> Так разговоры давно идут об введений подмножеств - урезанной современной версии языка.
> С выкидыванием всякого хлама,там такого всего накопилось ......Так то g++ заметно тормознее gcc... потому что C++ куда как более фичастый язык. И время жевания сорцов на плсоте - ну вот реально заметно дольше. Хоть там как.
И чё? Когда сам GCC c версии 4.8 тоже начал постепенный переход на C++, тоже ныли, мееедленно. Вот спустя десяток лет, полёт нормальный. Пользуемся и не замечаем. Уж некоторые и забыли/не знали, что он на C++.
> И чё? Когда сам GCC c версии 4.8 тоже начал постепенный переход
> на C++, тоже ныли, мееедленно. Вот спустя десяток лет, полёт нормальный.
> Пользуемся и не замечаем. Уж некоторые и забыли/не знали, что он на C++.А вы часто вот именно gcc сами компилите, чтобы разницу в времени компила gcc ощутить? Так то его заметно тормознее себе перекомпиливать стало. Я это еще и практикую, так что знаю о чем говорю.
На скорость работы скомпиленой прогрыммы это может и не влиять. А вот на скорость компила очень даже. Ну и вот проги на плюсах - заметно дольше компилятся "при прочих равных" (e.g. примрено одинаковая функциональность).
> Так то g++ заметно тормознее gcc...Это в прошлом было такое.
А сейчас что скорость компиляции примерно одинакова, с очень небольшим преимуществом gcc, в среднем, но не всегда.
Но нет дыма без огня. В разных сборках компиляторов скорость может отличаться в разы, например, бывает "хорошая" сборка g++ может быть заметно быстрее gcc или другой сборки g++. Такой бардак с компиляторами есть для esp32 и stm32, и вляпавшись в крайние отклонения в скорости компиляции "удачной" пары компиляторов можно сделать неверные выводы.При тесте на исходнике который могут переварить оба компилятора, нормальных сборок, то разница незначительна, и быстрее может оказаться и g++.
А если понаворотите кода, то логично, что работы станет больше, и оптимизировать тоже надо.А еще некорректно сравнивать скорость компиляции в отрыве от результата компиляции, а то clang часто быстрее g++, но у g++ бинарник получше на мой взгляд выходит.
> А сейчас что скорость компиляции примерно одинакова, с очень небольшим преимуществом gcc,
> в среднем, но не всегда.Угу, конечно. Запускаем допустим libaom компилиться. И чего-то сишная часть тикает быстро, а вот плюсатые - всего лишь тесты - куда скромнее по скорости сборки, при том что в общем то тесты довольно примитивные. Cmake индикатор прогресса кажет, в процентах, там хорошо видно кто тормоз.
> Но нет дыма без огня. В разных сборках компиляторов скорость
> может отличаться в разы, например, бывает "хорошая" сборка g++ может быть
> заметно быстрее gcc или другой сборки g++.У меня стандартный дебиановский gcc/g++ 12.x - такой как его дебиан отгружает. Васянские сборки я устанавливать не собираюсь хоть там как.
> Такой бардак с компиляторами есть для esp32 и stm32,
Я для STM32 собираю обычным дистровским же gcc-arm-none-eabi (впрочем и gcc-arm-gnueabihf катит). Но я для фирмварей только си юзаю. А зачем мне васянские сборки, опять же?
> и вляпавшись в крайние отклонения в скорости компиляции "удачной" пары
> компиляторов можно сделать неверные выводы.Вон то - совершенно типовой тренд для билдовки софта. Суммарно я так или иначе пробовал билдовать около 250 разных программ так что имел возможность заметить тренды. Они мало меняются по версиям системного gcc, g++ всегда заметно медленнее gcc как компилер.
> При тесте на исходнике который могут переварить оба компилятора, нормальных
> сборок, то разница незначительна, и быстрее может оказаться и g++.Возможно. Однако плюсатый софт в целом компилится весьма ощутимо медленнее. Ессно его нельзя собрать gcc для сравнения. Но например GTKшную морду трансмишна на си VS плюсатую на Qt - вполне, и в силу сравнимой функциональности можно прикинуть как мне время билдовки. И оно ессно не в пользу g++ от слова вообще.
> А еще некорректно сравнивать скорость компиляции в отрыве от результата
> компиляции, а то clang часто быстрее g++, но у g++ бинарник
> получше на мой взгляд выходит.Я выразил "интегральный" опыт - в целом плюсатый софт заметно тормознее в компиле. Вот хоть как. И тот же gcc после того как разрешили юзеж плюсов пересобираться стал ощутимо дольше, что в общем то и не фича вовсе.
>>А зачем мне васянские сборки, опять же?Если например пересборка компилятора esp32s3 и системы сборки сократила время сборки проекта с 40 до 8 секунд, то таких Васянов на руках носить надо.
Впрочем, раз Вы вполне опытный, можете собрать и сами. А если "Васяны" дали подсказку куда копать, то и их труды не пропали.>>куда скромнее по скорости сборки, при том что в общем то тесты довольно примитивны
Малый разрыв в скорости, это когда си-исходник собирается с++ компилятором.
Но это справедливо для одной версии и сборки компиляторов clang и gcc. А разные версии и сбоки могут отличаться как угодноЕщё на слабых для разработки компах, и тем более каких есть ноутбуках, свежие компиляторы в принципе медленнее старых версий их же самих. И разрыв между компиляцией си и с++ будет вполне заметен. А на среднемощном десктопе таки пофиг.
> Впрочем, раз Вы вполне опытный, можете собрать и сами. А если "Васяны"
> дали подсказку куда копать, то и их труды не пропали.Я ESP не использую, и врядли буду когда либо. Так что это знание может и будет полезно... но кому-то другому.
> Малый разрыв в скорости, это когда си-исходник собирается с++ компилятором.
Вы издеваетесь? Меня жонглирование цифрами не интересует, интересно время фактической сборки проектов. Зачем мне обманывать самого себя? И в этом смысле плюсовые проекты заметно тормознее билдить.
> Ещё на слабых для разработки компах, и тем более каких есть ноутбуках,
> свежие компиляторы в принципе медленнее старых версий их же самих. И
> разрыв между компиляцией си и с++ будет вполне заметен. А на
> среднемощном десктопе таки пофиг.У меня довольно мощный десктоп - и - боюсь я очень даже вижу разницу в времени билда старого gcc и нового где плюсоту можно стало, например. А по сравнению с кернелом gcc так то довольно небольшой проект. Заякорить билд кернела в пару раз было бы очень такой себе идеей. На разлапистой конфиге там и так время билда очень даже.
Как нас унесло. Изначальный смысл был скормить си исходники компилятору с++, а не переписывать, чем занята другая группа.Мощные десктопы на работе, и дома у любителей. У меня тоже есть и мощные.
Но случаи бывают разные. Банально что то поправить, и собрать не дома. Есть ещё командировки. И студенты в конце концов.>>плюсовые проекты заметно тормознее билдить.
Плюсовые, да, там же тупо язык сложнее. Но не такая редкость когда по сути си проекты, с минимумом фич от с++, или их отсутствием, собирают с++ компилятором. И тут, взависимости от стиля исходника, бинарник может получиться и лучше, и контроль типов получше, а разница во времени компиляции минимальна в подобных случаях.
Вообще, если не рассматривать ядро, то гораздо чаще сборку проекта можно ускорить не заменой компилятора, а его реорганизацией проекта, зависимостей, и правилами сборки, а то именно на мощных компах проекты "начинающих" и "консерваторов" не используют все ресурсы компа, и даже на мощной машине собираются неспешно.
> Как нас унесло. Изначальный смысл был скормить си исходники компилятору с++, а
> не переписывать, чем занята другая группа.Вот те раз. А я то думал изначальный смысл - оценить технологию, по возможности объективно и непредвзято. И в этом смысле меня таки как кастомщика и кернелбилдера в контексте сабжа беспокоит потенциал для обвала скорости компила в разы.
Да, C++ позволяет более выразительные конструкции. Если б еще наслоения легаси выкинуть, и оформить более безопасный subset дефолтов "для чайников" - был бы наверное неплохой яп так то. Но в случае с проектом размером с кернел есть много разных аспектов. Время компила напрямую влияет на допустим степень протестированности кода, да и скорость разработки якорит.
Не, коду который "haven't seen compiler" я не доверяю. Never had, and never will.
> Мощные десктопы на работе, и дома у любителей. У меня тоже есть и мощные.
Времена билда кернела могут напрячь и на таких. Помножить эти времена на эн - очень так себе идея. К тому же это все создает entry level barrier там где его быть не должно, отсеивая всяких студентов и ко. Зачем нам это проект без студентов и энтузиастов, где только мегакорпы?
> Но случаи бывают разные. Банально что то поправить, и собрать не дома.
> Есть ещё командировки. И студенты в конце концов.Ну дык. Чем злее требования к конфиге - тем меньше народа это все будет делать. Это идет вразрез с идеями опенсорса - и куда это заведет? К тому что пилить будут полтора корпората с билдфермами? Так что совсем игнорить этот топик имхо не стоит.
>>>плюсовые проекты заметно тормознее билдить.
> Плюсовые, да, там же тупо язык сложнее. Но не такая редкость когда
> по сути си проекты, с минимумом фич от с++, или их
> отсутствием, собирают с++ компилятором.Это в основном майкрософтовские кодеры таким страдают, как и юзежом си++ в режиме "чуть улучшеный си". Вызвано убогостью MSVS как си компилера, но в случае сабжа не аргумент ибо - unsupported config.
> И тут, взависимости от стиля исходника, бинарник может получиться и лучше,
С фига ли вдруг?
> и контроль типов получше,
Да вообще-то в сях он весьма даже. А если кто думал что знает о типах все, пусть попробует -Wconversion поюзать. И таки - компилер то может. А вот сможете ли вы с этим жить, если вам на pre-existing проекты вот такие жесткие проверки влепить...
> Вообще, если не рассматривать ядро, то гораздо чаще сборку проекта можно ускорить
> не заменой компилятора, а его реорганизацией проекта, зависимостей, и правилами сборки,Ну да, давайте искать не там где ключ потеряли, а под фонарем, потому что там светло. Вон то все же похоже на костыль или неизбежное зло, которым занялись от отличной скорости сборки плюсоты. Это конечно не оправдание для совсем уж хреновых подходов.
> а то именно на мощных компах проекты "начинающих" и "консерваторов" не
> используют все ресурсы компа, и даже на мощной машине собираются неспешно.Да вообще-то при пинке в кучу потоков процы оно нормально жрет и как раз упирается в именно проц. Вот особенно - плюсота как раз. Там именно g++ плотно проц грузит надолго, в остальное захочешь не упрешься. На сях там еще может быть всякий оверхед, io и проч, т.к. относительно резво билдует. Но в плюсах это как раз намного меньшая проблема.
А зачем вы его постоянно пересобираете?
2.6.32 работает - не трожь!
Потому что оно багованное.Проверяем, есть ли баги в новых версиях.
Так это ж надо желать один раз, когда хочется попробовать новую версию. А один раз - какая разница, сколько оно собирается? Это ж не 200 тысяч запросов в секунду где время обработки имеет значение.
> А зачем вы его постоянно пересобираете?Потому что его постоянно правят. Вот бы заморозили его разработку, да? Тогда можно было бы переписывать на любые языки и не заботиться о том, что кто-то захочет его собрать.
> А зачем вы его постоянно пересобираете?https://bellard.org/tcc/tccboot.html
а ведь когда-то можно было и так, игрушечным компилятором размером в 100кБ, написанным изначально вообще для ioccc.да и чего мелочиться, в ядре просто необходим питон, яваскрипт, го, и вижуалбэйсик!
и систему сборки ещё обязательно поменять, а то несовременно как-то.
опять огульные выдуми кро скорость сборки. когда же вы успокоитесь, выдумщики
>Запаримся пересобирать же! Си собирается намного шустрее.А что вы про Rust запоёте?
Судя по комментариям, большинство из тех, кто "поет" на OpenNET про Rust разбираются в нем примерно как свинья в апельсинах. Хотя, возможно, свинья разбирается все же лучше.
Хейтеры, которые ниАсилили. Естественно, что у любого, кто в теме вопли всяких криворуких рукожопов вызывают лишь гомерический смех.
PS Это не значит, что Rust идеальный и у него нет проблем. Некоторые вещи там сделаны не лучшим образом.
> В списке рассылкиШёл 2024 год...
П.с. Так там ещё и 80 символов ограничение 🤦♀️
> checkpatch/coding-style: deprecate 80-column warning
Отличное ограничение, ещё бы TABы сделали равными 4м символам или вообще заменяли бы их на пробелы
А лучше трем символам. Или может восьми, видел и такое.
В ядре как раз-таки 8
*стирает исходники ядра пры..линукса*
фу.
Яваскриптеры голосуют за два пробела.В общем, после окончания споров "табы/пробелы" появляется множество других интересных и продуктивных споров на тему того, сколько именно пробелов использовать. Таким образом, находится и работа для тех, кому код писать не получается, а поучаствовать в разработке охота.
Лучше пробелы, тогда форматирование не зависит от настроек редактора кода и, следовательно, не едет.
>Лучше пробелыНе лучше. Таб = 1 байт, пробелы >1 байта.
> Не лучше. Таб = 1 байт, пробелы >1 байта.И что?
> не зависит от настроек редактора кода и, следовательно, не едет.Ложь. Едет, если в редакторе настроена замена пробелов табуляциями. То есть от настроек редактора зависит.
едет, если умственно-ограниченные начинают использовать табуляцию не для индентификации кода (и использовать этот символ строго в начале строки до первого не-пробельного), но и пытаются табуляцией что-то форматировать в середине строки.
Фанаты пробелов - это потомки тех, кто в 90-х в офисе вместо настройки первой строки абзаца отбивали этот отступ пробелами.
Вы бредите. Табуляция - это табуляция, ОДИН символ. Что значит "равной 4 символам"?
TAB это терминальный опкод, а не символ. Ровно как и все ASCII символы до 0x20 не символы.
Ну пусть будет 1 оп. код вместо четырёх; есть же разница?
когда я в подном большом проекте заменил все отступы на табы (вместо 4 пробелов) и \r\n на \n, сэкономилось несколько МАГАБАЙТ. И это всё каждый раз парсилось ИДЕ, компилятором, гитом, архиватором...
> когда я в подном большом проекте заменил все отступы на табы (вместо
> 4 пробелов) и \r\n на \n, сэкономилось несколько МАГАБАЙТ. И это
> всё каждый раз парсилось ИДЕ, компилятором, гитом, архиватором...А еще на несколько мегов меньше читать и парсить (компилеру whitespaces до лампочки, это ж не питон). Тоже так то аргумент.
Производительность взлетела до небес, наверное.
Что такой тугой, TAB равен изначально 8-и символам и это неудобно. Что породило со временем кастомные настройки размера TAB-ов, например, более практичный 4 символа. И по факту теперь это плаваяющая единица из-за чего при разных настройках едет форматирование текста. Потому TAB в современном мире непригоден для использования. Ситуацию можно починить если вхерачить в UTF специальные коды для TAB-ов разного размера или же инструкцию с заданием длины TAB-ов.
Ещё раз, специально для вас.Форматирование при использовании табов едет только у тех, кто между табом и пробелом выбирает, бросая игральные кости. У тех, кто использует табы только для отступов, ничего не едет, а изменение размера табуляции позволяет сделать код более читабельным: кому-то комфортнее 8 столбцов в отступе, кому-то 2.
Какой и ты тугой. Форматирование в общем случае едет всё равно потому что TABы конкурируют с обычным текстом в соседних строках. Например, это разбивка длинных аргументов у функций на строки, это многострочные комментарии с развёрнутыми пояснениями, это идиотский GNU стиль расстановки скобочек {. И многое другое.> а изменение размера табуляции позволяет сделать код более читабельным: кому-то комфортнее 8 столбцов в отступе, кому-то 2.
Галиматью несёшь. Код сразу форматируется под конкретный размер TABа и с другими размерами форматирование едет
Типичный, кстати, пример, где всё это едет, как раз линуксовое ядро, которое пишется под стандартный TAB
> ТAB равен изначально 8-и символамДаже на печатных машинках Табы настраивались на любые позиции, не обязательно с шагом, а именно произвольно.
Бардак был изначально, но на бумаге выходили пробелы.
> Даже на печатных машинках Табы настраивались на любые позиции, не обязательно с
> шагом, а именно произвольно.
> Бардак был изначально, но на бумаге выходили пробелы.На печатных машинках чужие исходники не отображали так что там проблема с тем что форматирование не то как задумано и не возникала...
TAB - был не символом, а кодом движения печатающей головки или руки оператора.
Поэтому и проблем не возникало, потому что на экране или бумаге был текст с пробелами.А использовать TAB как символ в исходниках было ошибкой.
Да вообще тупые. Пора уже на слак перейти, или накрайняк на дискорд. Я уже устал читать их многостраничные сообщения в рассылке. В слаке или в дискорде каждое сообщение будет не более двух-трех строчек.
Лучше в твиттер (или как она там называется теперь)
... и до сих пор не придумали ничего лучше, чем форум. Даже в виде рассылки.
Подозревая, что в 2044 половина модных сервисов позакрывается, а списки рассылки и их архивы будут на месте.
>Шёл 2024 год...О, кто-то календарь перевернул!
> "Now, "why not Rust"? First of all, Rust uses a different (often, in my opinion, gratuitously so) syntaxЭто он ещё очень дипломатично выразился относительно этого нагромождения сокращений и спецсимволов.
А какая тебе разница, какие там спецсимволы? Тебе алгоритмы писать, а не буковки разглядывать. Так что пофиг какой в языке синтаксис, это вопрос десятый. Если уж так хочется - можно и DSL написать с другим синтаксисом.
Синтаксис очень очень важен именно для алгоритмов, сложного нетривиального кода.Код должен ясно передавать намерения (высокоуровневые) и идеи алгоритма.
Это как раз для передачи json по http синтаксис не столь важен, "можно потерпеть", не критично.
Попробуй разобрать алгоритм на brainfuck.
> Код должен ясно передавать намерения (высокоуровневые) и идеи алгоритма.Нет. Код должен реализовывать алгоритм, который описан обычным человеческим языком в комментарии прямо перед ним, а реализация должна быть обязательно аннотирована ссылками на это описание и, по необходимости, прокомментирована. В случаях когда реализация использует оптимизации (например, специфические для ЯП или аппаратной платформы), они обязательно должны быть прокомментированы с описанием оснований для принятия решения об оптимизации, списком рассмотренных альтернатив, результатами бенчмарков и снабжены тестами, эти самые бенчмарки реализующими. В противном случае действительно можно и на brainfuck писать с тем же успехом.
>> Код должен ясно передавать намерения (высокоуровневые) и идеи алгоритма.
> Нет. Код должен реализовывать алгоритм, который описан обычным человеческим языком в комментарии
> прямо перед ним, а реализация должна быть обязательно аннотирована ссылками на
> это описание и, по необходимости, прокомментирована. В случаях когда реализация использует
> оптимизации (например, специфические для ЯП или аппаратной платформы), они обязательно
> должны быть прокомментированы с описанием оснований для принятия решения об оптимизации,
> списком рассмотренных альтернатив, результатами бенчмарков и снабжены тестами, эти самые
> бенчмарки реализующими. В противном случае действительно можно и на brainfuck писать
> с тем же успехом.Это верно, но есть нюанс. Идея "самодокументированного кода" позволяет автору сохранить хоть какой-то контроль за проектом. Что важно, когда он лишается имущественных прав по лицензиям типа GPL. Потому имеем, что имеем.
> Это верно, но есть нюанс. Идея "самодокументированного кода" позволяет автору сохранить
> хоть какой-то контроль за проектом. Что важно, когда он лишается имущественных
> прав по лицензиям типа GPL. Потому имеем, что имеем.В каком месте GPL лишает кого-то имущественных прав? Цитату?
>> Это верно, но есть нюанс. Идея "самодокументированного кода" позволяет автору сохранить
>> хоть какой-то контроль за проектом. Что важно, когда он лишается имущественных
>> прав по лицензиям типа GPL. Потому имеем, что имеем.
> В каком месте GPL лишает кого-то имущественных прав?В месте замены "право" на "лево".
> Цитату?
"copyleft"
> В месте замены "право" на "лево".
>> Цитату?
> "copyleft"И где тут акт отчуждения прав происходит?
>> В месте замены "право" на "лево".
>>> Цитату?
>> "copyleft"
> И где тут акт отчуждения прав происходит?Наймите юриста, пусть он и разъясняет в подробностях, что такое copyright, и что такое copyleft. Мне в принципе не интересен данный разговор с тем, кто не может заявить "вот, смотрите, я создал проект под GPL", потому что такой -- материально заинтересованное лицо, не являющееся автором.
Код гораздо чаше нужно читать, чем писать. Поэтому, чем удобнее его читать, тем лучше. Си в этом плане кстати тоже не идеал, но определённо лучше Rust и C++.
>... но определённо лучше Rust и C++с этим тоже можно поспорить, т.к. на читиаемость влияет и количество строк и goto всякие.
В С++ есть большая проблема -- ссылки в перечне параметров функции. Это препятствует использованию там r-value. А как известно, любое l-value в программе добавляет +1 к пулу потенциальных проблем безопасности и программных ошибок.
Что касается goto, то без него вы даже из вложенного цикла не выйдете. Вернее, выйдете, но через виртожопу.
>Что касается goto, то без него вы даже из вложенного цикла не выйдете.Что касается "обычных непричин", нон-секвитуров и прочих нерелевантных доводов, выходы из вложенных циклов просто свидетельство каши в коде и в голове разраба.
>Вернее, выйдете, но через виртожопу.
Из через жопу написанного кода любой выход только такой. И с помощью goto в первую очередь.
Ну так пройдитесь просто по двумерному массиву. Когда-нибудь изображения обрабатывали? А гиперспектральные, которые трехмерные массивы?
Парсер простой напишите без goto для какого-нибудь примитивного языка, например, для джейсона. Все без исключения FSM-алгоритмы, коими и являются эти самые синтаксические анализаторы, работают на goto безальтернативно.
>Что касается goto, то без него вы даже из вложенного цикла не выйдете."Cache-friendly программирование? Не, не слышали." И продолжили выходить из вложенных циклов... А главное, писать вложенные циклы.
>>Что касается goto, то без него вы даже из вложенного цикла не выйдете.
> "Cache-friendly программирование? Не, не слышали." И продолжили выходить из вложенных
> циклов... А главное, писать вложенные циклы."Каше-френдли" программирование начинается прежде всего с безальтернативного использования статических библиотек вместо динамических и минимизации длинных переходов. Причем прежде всего это касается вызовов процедур, поскольку каждый call сопровождается еще и ret'ом. Итого два сброса всех кешей кода в одном вызове.
А короткие переходы, которые в основном и генерируются из goto, кеши кода не портят, поскольку все это происходит в пределах одной страницы. Причем и кеши данных не сбрасывают тоже, поскольку к памяти данных/стека, в отличие от call/ret не обращаются.
Кстати, обращение к любой функции в .so несколько раз сбрасывает все кеши, что есть. Сначала дальняя ссылка на GPT, потом дальний переход на процедуру и потом возврат из дальнего вызова.Есть несколько постулатов, используемых, в том числе, и в программировании, следование которым позволяет серьезно повысить качество программ. Это:
1) явное всегда лучше неявного;
2) административные проблемы плохо решаются техническими средствами, а технические -- административными, поэтому "Каждому свое", как было написано на воротах одного гуманитарного заведения.
Эти два пункта относятся прежде всего к стилям програмирования, в том числе и к goto. Смысл состоит в том, что проблемы, проистекающие из-за хреновых навыков программирования (это всегда у нас и у них тоже называлось "логические ошибки"), невозможно адекватно решать с помощью каких-то особых и "безопасных" языков программирования. Все эти якобы "безопасные" парадигмы и языки поголовно работают поверх кода, написанного на сях, да и сами в 99% случаях написаны на них же, представляя просто фреймворк. Питон, например, один из них. Второй момент -- их использование не дает прграммисту расти. Он просто скачет от одной "технологии" к другой, оставаясь на уровне своего лучшего курсового проекта. Умение работать с памятью приходит только с опытом работы с ней и никак не иначе.
Предсказание и предвыборка команд работают для call/ret начиная с NetBurst (и для far call/ret работают, но эти команды не используются в плоской модели памяти). Но это не повод отказываться от статического связывания.Calls and returns are expensive; use inlining for the following reasons:
• Parameter passing overhead can be eliminated.
• A mispredicted branch can lead to performance penalties inside a small function that are larger than
those that would occur if that function is inlined.
• In a compiler, inlining a function exposes more opportunity for optimization.
• If the inlined routine contains branches, the additional context of the caller may improve branch
prediction within the routine.
И Rust и C++ более выразительные языки чем C, и именно поэтому код на них гораздо проще читать.
Оба языка позволяют как написать очень выразительно, так и нечитаемо, или понимаемо, но не так. ;)
То есть, в плане оформления исходника, позволяют "прострелить себе ногу".
Несмотря на то, что я топлю за C++, не могу не придраться, что C++ ОЧЕНЬ опасен в плохих руках и там легко допустить плохие решения (как по семантике, так и по читаемости кода). Но преимущество C++ в том (и об этом говорили многие задолго до китов), что C++ напрямую связан с C и всё можно переписывать плавно не боясь что-то сломать.
Ну и че ты не переписал еще все ядро на brainfuck?
Так сокращения это норма для линукса. cp, mv, dd, rm, ls, df, du, pz
Это объясняется легаси.
Могу назвать ещё минимум две причины, по которым
ls -l
Лучше, чем
list-files-and-directories --show-as-much-details-as-possible
> Могу назвать ещё минимум две причины, по которым
> ls -l
> Лучше, чем
> list-files-and-directories --show-as-much-details-as-possibleВы только что рассказали почему powershell - ацтой каких мало. Ах да, автодополнение в том уродце не работает по сути никак, чтобы вы уж точно сломали пальцы. Как-то так и понимаешь где индусы, а где гении.
Наоборот же, powershell показывает, что можно всем угодить изкоробочными алиасами и parameter name matching'ом (-def ниже, как одна из недвусмысленных подстрок, с которых начинается параметр -Definition).> get-alias ls
Alias ls -> Get-ChildItem
> get-alias -def get-childitemAlias dir -> Get-ChildItem
Alias gci -> Get-ChildItem
Alias ls -> Get-ChildItem
> Наоборот же, powershell показывает, что можно всем угодить
> изкоробочными алиасами и parameter name matching'омОн мне так угАдил своим синтаксисом, километровыми командами и очешуенным временем старта на виртуалках что я как раз и развидел маздайку к хренам. И назад уже никогда не вернусь, хоть там что. Простите но какую задачу решает (ba)sh я понимаю. Какую задачу решает это индусское месиво я не понимаю. Мне такой шелл - без надобности. Совсем. Одно это уже бьет наповал ваше "всем" наличием конкретного контрпримера.
Не, я в принципе не собираюсь столько на клаве печатать в шелле. А когда там еще и автодополнение такое как там, пути с пробелами, и брейнфак с типизацией (в шелле!!!) - ну, знаете, вот пусть авторы этого и пользуются им.
> Какую задачу решает это индусское месиво я не понимаю.
> брейнфак с типизацией (в шелле!!!)Ну жирноват-тяжеловат он, но вот идея типизированного шелла должна быть понятна. Должно быть понятно, зачем линуксоиды делают свой powershell в виде nushell.
> Ну жирноват-тяжеловат он, но вот идея типизированного шелла должна быть понятна. Должно
> быть понятно, зачем линуксоиды делают свой powershell в виде nushell.В результате самое крутое что есть в шелле ака мелкая автоматизация системной рутины по месту - здесь и сейчас - там по сути и невозможна. Эффективного интерфейса к системе - нет.
Печатать километровые команды и параметры, с почти неработающим автодополнением, а вишенкой на торте еще и пути с пробелами и проч везде (хотели же длинно и интуитивно?) - это здорово, конечно, только в результате я то же самое в лине раз в 5 быстрее делаю. А если еще типизация начнет делать мозг... эээ... ну в общем сделать пайплайн там чаще всего не получается. А если я хотел похардкорить с мощным программизмом - не совсем понятно зачем это в вот именно шелле делать. Оно ж не ide, и с автодополнением джеппа.
Тебя опять что-ли шиза долбает, 294й? То что по умолчанию идёт с PSReadLine ты оппрыгаешься с башем. Алиасы давно по умолчанию сделаны и выглядят практически как в баш. Если ты в пайплайны не умеешь в ps - иди в дворники.
А ещё, для автоматизации быстрой, жду аналог PowerCLI для vmware. Ты же в 5 раз быстрее сделаешь в лине. Покажи примеры.
> Тебя опять что-ли шиза долбает, 294й? То что по умолчанию идёт с
> PSReadLine ты оппрыгаешься с башем.Ну во первых я вобью проблему в поискарь и скопипащу 90% решения. Во вторых я не собираюсь бузинесс-логику или что там еще на шелле бжад наворачивать. Поэтому в 95% случаев мне вон то просто не приболело, а вот минусы - икнутся.
> Алиасы давно по умолчанию сделаны и выглядят практически как в баш.
А внутрях все равно летающий спагетти монстр с километрами макарон, норовящий типизацией куснуть и чего там еще. И время старта этой байды такое, что у меня в ряди случаев скрипты отработают быстрее чем ЭТО вообще только стартануть расчехлится на VM.
Ну я и не понял зачем мне такой шелл надо, не разгоняет мою эффетивность и создает больше проблем чем решает. Не, я не хотел хардкорить в шелле. Для этого другие яп есть.
> Если ты в пайплайны не умеешь в ps - иди в дворники.
Я пошел в пингвина вместо этого - там с пайплайнами ноу проблем, и вообще, все как-то сильно проще и ненапряжнее. Можно сделать что хотел а не пытаться косплеить лучшие практики мега-иде зачем-то бжаж в шелле, где для этого инструментации нет.
> А ещё, для автоматизации быстрой, жду аналог PowerCLI для vmware. Ты же
> в 5 раз быстрее сделаешь в лине. Покажи примеры.Ну так я себе ряд операций с виртуалками прекрасно оптимизнул. Конечно для KVM и QEMU, нахрен мне вмварь? Более того - я себе _генерацию_ дебутстрапом наваял - с моими кастомизациями. У вас там уровень сцаного эксплуатанта. А я кастомдев, мне больше надо. На баше я это забацал минут за 10. А на этой повар-щели я бы часами долбался с тем же самым, воюя с не теми типами данных мля, и чем там еще. Оно мне надо?!
А, да, ваш коллега пох (или нах?) таки - вот - плакался что вмварь сожрали. Вас ждут интересные времена! И хорошо что все это - не у меня :)
> Ну во первых я вобью проблему в поискарь и скопипащу 90% решения.У тебя как 294й, с способностью понимать тексты? Проблема?
Скопипасть в поискарь и найди что делает PSReadLine, потом рассказывай как в баш это круто.> Во вторых я не собираюсь бузинесс-логику или что там еще на шелле бжад наворачивать. Поэтому в 95% случаев мне вон то просто не приболело, а вот минусы - икнутся.
О, опять очередной передерг. Аж два сразу.
Во первых бизнес-логика. Про неё тут никто и не говорил.
Во вторых примудил мифические минусы. Которые кроме тебя никто не наблюдает.> А внутрях все равно летающий спагетти монстр с километрами макарон, норовящий типизацией куснуть и чего там еще. И время старта этой байды такое, что у меня в ряди случаев скрипты отработают быстрее чем ЭТО вообще только стартануть расчехлится на VM.
Это любители башпорятнок рассказывают? Ну те что в соседних треда точно такой же аргумент приводят на тему системд и другой системы инициализации. Только там лапша в баше у них.
Ты про алиас то в поисковик можешь вбить болезный? Ну и показать насколько букв команда в баше cd больше цмдлета в пауршеле cd?
Хотя у кого хаотическое мышление им действительно не понять - как это правила именования команд сделать и их соблюдать. А поверх сделать просто алиасы.
Ну про телегу разных шелов и разное поведение в разных ОС вообще промолчу. Переносимость это не про тебя. Как же ты лохов обувать будешь, если подпиливать твои портянки не надо будет под каждый чих.
Проще в несколько команд прогнать объект и вытащить нужный процесс по тому же показателю памяти. Чем писать десятки строк под каждую ОС и шел. Мне своё время дороже. Но твоё ничего не стоит, поэтому пиши партянки с макаронинами под мак-вин-лин и разные шелы.> Я пошел в пингвина вместо этого - там с пайплайнами ноу проблем, и вообще, все как-то сильно проще и ненапряжнее.
Ну так все и поняли что ты не умеешь в пайплайны. Сейчас в куче мест ушли все в курьеры. Мест для дворников полно. Сходи - пособеседуйся. Там твоё место.
> Ну так я себе ряд операций с виртуалками прекрасно оптимизнул.
Опять передерг. Никого тут и в мире не интересуют твоё пердольнье с ардуинками, мелкими виртуалочками и прочим компостом. Нужна "плаформа" для возможности быстро решить задачу. Давай наналог PowerCLI для kvm. Тебя больного с баш-портянками в комплекте к сервису нормальным людям не надо.
> Более того - я себе _генерацию_ дебутстрапом наваял - с моими кастомизациями.
Да понятно что ты с пердуинками там балуешься, но тут ты этим никого не удивишь.
> У вас там уровень сцаного эксплуатанта.
Бгыыых. Тебе то виднее у кого что. Гусар-одиночка с пердуинками на шеле пишет письмо сатья-наделле, картина маслом.
> А на этой повар-щели я бы часами долбался с тем же самым, воюя с не теми типами данных мля, и чем там еще. Оно мне надо?!
Да все уже поняли что ты головка от патефона. Не пробовал это сделать но мнение имеешь.
> А, да, ваш коллега пох (или нах?) таки - вот - плакался что вмварь сожрали. Вас ждут интересные времена! И хорошо что все это - не у меня :)
Ты не поверишь. powershell от этого никуда не денется. Как и модули к остальным виртуальным средам.
Резюмируя. Ни одного ответа на вопрос ты не дал, только попередергивал. Хвост павлиний распушил.
Скажи а вот твоё инфоцыганство здесь помогает тебе дуриков находить?
> Скопипасть в поискарь и найди что делает PSReadLine, потом рассказывай как в
> баш это круто.Меня от шелла интересует 2 сценария: oneliner руками на 1 раз, "here and now". Либо batch mode штука, управляемок параметрами командлайна. Зачем мне вон то я хз.
Пытаться из шелла крутую среду программирования? Бессмысленно и беспощадно.
> Во вторых примудил мифические минусы. Которые кроме тебя никто не наблюдает.
Я и смотрю, аж виндузеры WSL что-то полюбили.
> Это любители башпорятнок рассказывают? Ну те что в соседних треда точно такой
> же аргумент приводят на тему системд и другой системы инициализации.Странно что я ненавижу спагетти код независимо от яп? Но у баша в целом команды и параметры лаконичнее в разы. Печатать меньше -> трабл решается быстрее.
Системд приветствуется ... по той же причине. У меня даже есть гибриды, где шелл и systemd играют в унисон, на пару. Скрипт прописывает и активирует юнит. Юнит потом тоже запускает скрипт. Я использую плюсы тулсов оставляя минусы за бортом. А в целом оркеструется забавное действо бутстрапа VM с минимумом возни.
> Только там лапша в баше у них.
А я ей ТАМ и не хочу пользоваться, если можно это урезать. Но кастом это кастом, там скрипт пригодится уже. Просто точек кастомизации 1-2, а остальное из фич системды и сделано.
> Ты про алиас то в поисковик можешь вбить болезный? Ну и показать
> насколько букв команда в баше cd больше цмдлета в пауршеле cd?Ага, костыли фичой объявить. Это в духе MS.
> правила именования команд сделать и их соблюдать. А поверх сделать просто алиасы.Шелл создан для автоматизации хаоса. Он хаотичен в 95% случаев. А концептуальную архитектуру проекта, клевые апи и структуры уместнее разводить где-то еще.
> промолчу. Переносимость это не про тебя.
Я могу в стандартный "posix shell" уложиться если это принципиально. А ps нигде кроме винды нет по сути. Но винда и мак для меня не в приоритете. Я инструментирую R&D линуха, это уместнее из линуха.
> Как же ты лохов обувать будешь, если подпиливать твои портянки не надо будет под каждый чих.
Майнтайнить шеллскрипты? Мсье знает толк...
> Проще в несколько команд прогнать объект и вытащить нужный процесс по тому
> же показателю памяти.Я не хотел крутое програмирование в шеле, я хотел мелкую автоматизацию по месту и быстрое решение насущных проблем. Если вам то проще, вы это и делайте. Мне это не надо от шелла.
> Чем писать десятки строк под каждую ОС и шел.
Я могу писать под posix shell, если надо. А ps на осях отличных от винды не в ходу вообще.
> пиши партянки с макаронинами под мак-вин-лин и разные шелы.
Пишу либо "под posix shell" - максимального компат, либо "под баш", 2 конфиги максимум.
> Ну так все и поняли что ты не умеешь в пайплайны.
У меня нет цели изобразить фантомаса в очках на аэроплане любой ценой из той кривули.
> Сходи - пособеседуйся. Там твоё место.
У кого что болит, видимо.
> Опять передерг. Никого тут и в мире не интересуют твоё пердольнье с
> ардуинками, мелкими виртуалочками и прочим компостом.Оно меня интересует. А так в баш и позиксшелл многократно больше народа могет, есчо.
> Нужна "плаформа" для возможности быстро решить задачу.
Кому нужна - тому и карты в руки! С фига меня ваши задачи должны волновать больше моих хз. Для меня мои задачи приоритетнее, збс должно быть - там.
> Да понятно что ты с пердуинками там балуешься, но тут ты этим никого не удивишь.
Дреппера vs arm напоминает. И вот где дреппер а где арм теперь? :)
> пишет письмо сатья-наделле, картина маслом.
Мне от этих раджа-насреддинов к счастью ничего не надо.
> Не пробовал это сделать но мнение имеешь.
Я много чего еще не пробовал, в этом мире много странной хни.
> Ты не поверишь. powershell от этого никуда не денется. Как и модули
> к остальным виртуальным средам.А вон то знание может вскоре стать бесполезным хламом. Да и быть придатком к 1 корпорации мне как-то так себе. А что и куда денется - решаете не вы а менеджмент этой корпы. И я видел как они росчерком пера проекты в утиль - хрясь.
> Резюмируя. Ни одного ответа на вопрос ты не дал, только попередергивал. Хвост
> павлиний распушил.А я и не собирался играть по вашим правилам. Поздравляю с прозрением.
> Скажи а вот твоё инфоцыганство здесь помогает тебе дуриков находить?
Оно помогает мне находить единомышленников. Вместе мы надерем ваши задницы по полной программе. Есть такое ощущение.
Резюмируя два.
Инфоцыган 294й забыл сам с чего начал(автодополнения нет, коротких команд нет и т.д.). Определенные решения системы становятся плюсами или минусами в зависимости от того по какие системы сравниваются. Лапша шела vs системд конечно в плюс системд. Лапша шела vs пауршел конечно в плюс шела. Алиасы в шеле vs алиасы пауршела конечно в плюс шела. Короткие ничерта не понятные команды в шеле vs длинные опции в системд конечно плюс системд. Короткие ничерта не понятные команды в шеле vs длинные команды по стандартам в пауршел конечно плюс шела.
Ну и дальше портянки художественного свиста. В конце не преминул рассказать про свои латентные потребности. Как же 294й да про орган которым думает не расскажет.
Инфоцыган, тебе самому позориться не смешно? Ты же не тянешь в дискуссию. На работу тебя подрядить нельзя - это же по комментам видно что ты за работник.Ты так и не рассказываешь. Что у тебя с повреждениями головного мозга была? Чего скрывать то?
> автодополнение в том уродце не работает по сути никак,А когда пишешь скрипт в любимом редакторе, то никакого автодополнения для этого чудовища вовсе нет.
Это объясняется тем, что всё это нужно постоянно набирать. Что касательно rust, то сокращения норм, но не норм | и '. Если с ' ещё как-то можно понять зачем пришлось так сделать, то накой хер взяли | понять уже сложно, ровно как и для чего напичкали ЯП вредными элементами функциональщины. В совокупности падает читабельность кода.
То-то наверно лучше в C++ когда звёздочка обозначает сразу 4 разных операции. А без функциональщины, лямбд современный язык уже не язык. В Rust итераторы более читабельные, чем императивная возня с указателями. В C++ между прочем тоже лямбды есть со своим специфическим синтаксисом.
> First of all, Rust uses a different (often, in my opinion, gratuitously so) syntaxИли это значит "мои старческие мозги скатываются в деменцию, новых символов отличных от 'в С/С++' я запомнить не могу; пожалейте старичка"
Или это значит, что разработчики Раста не смогли осилить нормальный синтаксис, а сейчас уже поздно.
Это значит лишь то, что Линус, будучи взрослым человеком, способен определить что является его персональным мнением, а что объективной реальностью, о чём и пишет («in my opinion»). Опеннету бы поучиться у него.
Линуса просто уже ранее настойчиво попросили быть повежливее..Странно что еще никто не запостил: http://harmful.cat-v.org/software/c++/linus
C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.
и про ядро:
In fact, in Linux we did try C++ once already, back in 1992.
It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
> Линуса просто уже ранее настойчиво попросили быть повежливее..
> Странно что еще никто не запостил: http://harmful.cat-v.org/software/c++/linus
> C++ is a horrible language. It's made more horrible by the fact
> that a lot of substandard programmers use it, to the point
> where it's much much easier to generate total and utter crap
> with it. Quite frankly, even if the choice of C were
> to do *nothing* but keep the C++ programmers out, that in
> itself would be a huge reason to use C.На это я отвечал в #211
> и про ядро:
> In fact, in Linux we did try C++ once already, back in
> 1992.
> It sucks. Trust me - writing kernel code in C++ is a
> BLOODY STUPID IDEA.И на это тоже. Правда, не на цитату Линуса, а на изложенный экспертом похожий смысл. Подсказывать не хочу -- думайте сами над очевидным ляпом, если считает себя знатоком С++.
Легендарная битва. Интересно чем закончится. Но сразу и Rust и C++ одновременно - это совсем не good.Эх, жаль некому также топить за Zig (и он недостаточно стабильный для ядра).
У C++ сейчас второе, или даже третье дыхание. По моим личным ощущениям.Но за Rust хайп и очень фанатичное комьюнити, которое толкает его куда только можно.
Что лучше подходит конкретно для ядра... ОДНОЗНАЧНО zig.
Комьюнити, которое хочет, чтобы кто-то другой на этом языке писал.
По моим, наверное, второе дыхание было с C++0x/C++1y. А вот уже с C++1z/C++2a и дальше язык просто рванул в космос.
> Что лучше подходит конкретно для ядра... ОДНОЗНАЧНО zig.Как там у него с портабельностью и вообще готовностью к проду? Вот представьте что завтра билдим кернел им для вашего десктопника. Как, прокатит? Без факапищ?
К сожалению, нет. Я и говорю что некому топить за него.Топить - не только в рассылках писать "а давайте zig", а именно допилить до применения в ядре.
Основа там заложена очень крутая.
> К сожалению, нет. Я и говорю что некому топить за него.
> Топить - не только в рассылках писать "а давайте zig", а именно
> допилить до применения в ядре.
> Основа там заложена очень крутая.Ну, говоря за себя - если у них референсная реализация на LLVM я лучше тогда хруст поизучаю. Когда в gcc нормально запилят, не раньше. Зависеть на 100% от выходок гугли и эпла как-то не хочется. Тем более что эпл уже начал характерную бадягу с особенным, уличным LLVM в Xcode для себя и вторым сортом - для остальных.
В основном языки имеют одну реализацию. С++ в этом плане является прям крайним исключением, просто так сложились обстоятельства. Как и С.Rust никогда не будет допилен в gcc. Я специально смотрел - пилят какие-то энтузиасты, один на магистра в универе учится. Это полуальтруисты.
Базовых вещей не умеет. Для ядра это наверное не будет пригодно никогда (в обозримом будущем).
Но пропихнуть Rust в kernel это не помешало 😄
> В основном языки имеют одну реализацию....гарантирующую 100% вендорлок, что после си и си++ как бы нефиговый регресс, есчо.
> С++ в этом плане является прям крайним исключением, просто так сложились обстоятельства.
Да, нашлись те кого вендорлоки заколебали. И я вовсе не для того пришел в опенсорс чтобы наслаждаться вендорлоками. Сюрприз! Never again! Так что у меня будет или так - или я поюзаю си и си++, мне хватит.
> Как и С. Rust никогда не будет допилен в gcc. Я специально смотрел - пилят
> какие-то энтузиасты, один на магистра в универе учится. Это полуальтруисты.Однако вон там уже и borrow checker прорезается. Во всяком случае я вижу какие-то коммиты связанной инфраструктуры.
А так Столлман написал первую версию gcc, Торвальдс накатал в 1 лицо Linux, упрямец Кент cow файлуху своротил. Большие вещи начинаются с малого.
> Базовых вещей не умеет. Для ядра это наверное не будет пригодно никогда
> (в обозримом будущем). Но пропихнуть Rust в kernel это не помешало 😄Ну он так пропихан что пока на него ничего реально не завязано. И кмк решение будет ли на него что-то завязано более плотно - ощутимо зависит от того будет ли gccrs юзабельным или нет. Майнтайнеры линуха тертые калачи и влопаться в вендорлок? Ну, эт, Торвальда уже пробовали так лохануть в Bitbaker. И где этот их bitbaker теперь?...
> У C++ сейчас второе, или даже третье дыхание. По моим личным ощущениям.Почему? Они насмотрелись на rust и другие языки и начали стандартизовывать нужные всем вещи?
Скорее они насмотрелись на D, а хайп вокруг безопасности заставил оторвать кое-что от стула.
> заставил оторвать кое-что от стулаПару ножек?
>> У C++ сейчас второе, или даже третье дыхание. По моим личным ощущениям.
> Почему? Они насмотрелись на rust и другие языки и начали стандартизовывать нужные
> всем вещи?А в rust что-то вообще СТАНДАРТИЗОВАНО?! У него ж ни единой версии стандарта нет. По крайней мере от нормальных standard body. Не, куча хипстеров хаотично корежащих синтаксис под заскоки левой своей пятки и приказ своего корпо-хозяина - это не оно. Вообще совсем. И вот как-то так получается что у хруста нет вообще ни 1 стандарта. В отличие от C++.
типа на стандартном С можно ядро написать!?вот умора, язык разработан для написания ядер и прочей системщины более 50 лет назад.
имеет нескольео стандартов ,но без гну/ms костылей ядра ОС так и не собираются.и эти же "стандартизаторы" вещают про стандарты.
> типа на стандартном С можно ядро написать!?Ну, почти. Режим freestanding официально специфицирован с C99 аж. Там правда пары вещей не хватает, это таки вот именно гнутые экстеншны.
> вот умора, язык разработан для написания ядер и прочей системщины более 50
> лет назад. имеет нескольео стандартов ,но без гну/ms костылей ядра ОС так и не
> собираются. и эти же "стандартизаторы" вещают про стандарты.Потому что в целом код conformant, плюс-минус очень небольшое число мест. А хруст вообще хаотичная помойка, развиваемая абы как. Захотели и перефигачили синтаксис. Наверное так и надо...
> Там правда пары вещей не хватает ...дооо, язык создавался для симстемщины и ядер ОС, но стандартизировать решили что-то другое.
Отличные стандарты! 🤣
>А хруст вообще хаотичная помойка, развиваемая абы как. Захотели и перефигачили синтаксис.Именно поэтому компиляция ядра клангом периодически отваливается? ведь так?
Это не потому что гнугники что-то постоянно подпиливают в своих нестандартных экстеншонах?
СТАНДАРТ !!! о таком только мечтать!
> дооо, язык создавался для симстемщины и ядер ОС, но стандартизировать решили что-то
> другое. Отличные стандарты! 🤣Хрустики даже и так не смогли. Все познается в сравнении... которое они и не выдерживают пока, демонстрируя шоу "хаотичная помойка имени питоняш".
>>А хруст вообще хаотичная помойка, развиваемая абы как. Захотели и перефигачили синтаксис.
> Именно поэтому компиляция ядра клангом периодически отваливается? ведь так?В хрусте системщина вообще в зачаточном состоянии и там вообще не привалилось еще толком - чтобы вообще начать отваливаться. Иногда удается что-то на проволоку и изоленту примотать, чуть ли не с gcc'шным, мля, линкером на страпоне, ибо свой - УГ. Но это видимо не пахнет. Но конечно вы можете скачать ночнушку, высокобезопастным инновационным curl | sh. Там может быть если повезет, уже почти, вот вот, ых, ых, ых... как как грите, фукмсию решили отменить когда как раз почти треть переписали? Ну, во, все правильно сделали. Сразу видно wannabe-успешный проект. Успешно присоединится к Wave, Plus, Picasa и кому там еще в Валхалле.
> Это не потому что гнугники что-то постоянно подпиливают в своих нестандартных экстеншонах?
> СТАНДАРТ !!! о таком только мечтать!"Но тут снизу постучали" - это были хрустики.
>Хрустики даже и так не смогли.Хрустики смогли пробиться в ядро, а С++ со всеми своими стандартами не смог.
Очередной пример, указывающий что стандарты это что-то бесполезное на практике.>чуть ли не с gcc'шным, мля, линкером на страпоне,
нет никакого gcс'шного, мля, линкера. есть GNU Binutils.
и тут хрустики тоже поступили практично, как и gcc'шники.
> Хрустики смогли пробиться в ядро, а С++ со всеми своими стандартами не смог.Они пока так пробились что постоянно переделывают свое месиво, постоянно надо самую-самую ночнушку, иначе нихрена не получится, в общем, самый прод. Я допускаю что из этого постепенно может и получится что-то дельное. Но пока это выглядит весьма хаотично, а нужда постоянно тягать начнушки яп намекает на д@рьмовый дизайн где многое не предусмотрели.
> Очередной пример, указывающий что стандарты это что-то бесполезное на практике.
Ну да, намного лучше, когда кучка хайпующей хипстоты вываливает в синтакс какое-то уг для ублажения сиюминутных хотелок своего вендора. А в результате синтаксис корежат хуже чем у питона, без скачки ночнушки нихрена не работает, и полезные продукты на этом уже прямо захватили мир. Куда там плюсерам до этого, действительно.
>>чуть ли не с gcc'шным, мля, линкером на страпоне,
> нет никакого gcс'шного, мля, линкера. есть GNU Binutils.Как минимум это все - вообще не заслуга хрустиков.
> и тут хрустики тоже поступили практично, как и gcc'шники.
Ну вот я подожду gccrs и там подумаю - надо оно мне или нет. LLVMный змейгорыныч мне не приболел, я не фанат ни гугли ни эппла, это те еще кидалы.
> Они пока так пробились что постоянно переделывают свое месиво ...ты как ни плюйся желчью, а факт есть факт. раст в ядре. а плюсы нет.
>Куда там плюсерам до этого, действительно.
точно не в ядро.
>> нет никакого gcс'шного, мля, линкера. есть GNU Binutils.
>Как минимум это все - вообще не заслуга хрустиков.это как раз показывает что хрустики практичные.
и да, это так же не заслуга приплюснутых.>Ну вот я подожду gccrs и там подумаю
ага, держи нас в курсе. всем очень интересно (нет).
> ты как ни плюйся желчью, а факт есть факт. раст в ядре. а плюсы нет.В ядре много чего было. И не все из этого с нами сейчас. Так что это само по себе еще ничего не означает. С другой стороны - может из этого и выйдет что-то дельное постепенно. Но пардон, качать ночнушки компилера - не стандарт а хипста-треш.
>>Куда там плюсерам до этого, действительно.
> точно не в ядро.Они чем-то принципиально хуже хрустиков?
> это как раз показывает что хрустики практичные.
Если бы они были бы практиными, потратили бы немного больше времени на архитектуру и изучение чужих фэйлов, тогда не приходилось бы перекачивать постоянно компилер и корежить синтаксис. Но с этим кажется облом вышел.
> и да, это так же не заслуга приплюснутых.
А бинутилсам плюсы юзать не разрешили случайно? В гцц - точно можно.
>>Ну вот я подожду gccrs и там подумаю
> ага, держи нас в курсе. всем очень интересно (нет).Да вы и кернел линуха врядли трогаете даже трехметровой палкой, так что...
>Эх, жаль некому также топить за Zig (и он недостаточно стабильный для ядра).Возможно потому что его компилятор работает только на последних версиях систем?
Там llvm. Всё что поддерживает llvm в целом должен или может поддерживать Zig.https://docs.kernel.org/kbuild/llvm.html
Да и ядро и так компилится с помощью llvm.
Вот только для ядра будет требование сборки с использованием gcc.
Для раста из-за этого начали делать gccrs, было утверждено добавление GCC 13 (https://www.opennet.dev/opennews/art.shtml?num=57491) в виде беты и так далее.
А что у Зига? Разве есть хоть какие-то подвижки?
Ну, вот и нужны кто будет двигать Zig и возьмётся за добавление к gcc. Это должны быть компании, но таких пока нет.
> Там llvm. Всё что поддерживает llvm в целом должен или может поддерживать Zig.Тогда EPIC FAIL - он получает тот же отлуп что и хруст в сравнимой дискуссии в git, ибо LLVM не особо то кроссплатформенная штука и далеко не все архитектуры поддерживает. Здорово сливая GCC по поддержке железа.
У LLVM все прекрасно с поддержкой платформ.
Это GCC поддерживает всяких хлам и некроплатформы
> У LLVM все прекрасно с поддержкой платформ.
> Это GCC поддерживает всяких хлам и некроплатформыну, ладно выкинут поддержку неподдерживаемых платформ из ядра, потому что, допустим, ядро пишут для llvm, а не наоборот. Но с этим https://clangbuiltlinux.github.io/ что делать? Оно ж тупо не собирает ядро трехлетней давности, Карл!!!
> ну, ладно выкинут поддержку неподдерживаемых платформ из ядраПри чем тут все платформы? Зачем тебе новейший драйвер напр. сетевухи на 100Гб на PDP-11 или System/370?
Сильно убудет если он не будет там поддерживаться, если он не компилится из-за шланга? Шланг даже m68k тяшет.
Приведи пожалуйста пример, отсутствие какой архитектуры - блокер.> Оно ж тупо не собирает ядро трехлетней давности
А ты обратил внимание, что андроиды собираются все, кроме android15‑6.6 старыми шлангами?
Не задумался почему так? Может просто гугл следит за этим и исправляет в ядре/шланге что нужно?
Вот если и в ядре будут следить, то компилится будет. Или ты думаешь что gcc просто самом собой начинает поддерживать все без проблем?
> У LLVM все прекрасно с поддержкой платформ.
> Это GCC поддерживает всяких хлам и некроплатформыBSDшники уже пробовали рассказывать сказку про (не)нужные всем фичи. И где они теперь? Вот и вы туда же с этим всем отправитесь. По тем же причинам. Мне вот например не нужны тулчейны где так внаглую лечат что мне (не)нужно. Я и не буду такими тулчейнами пользоваться.
Да нет там никакой битвы, тем более легендарной. Очень вялая дискуссия где одни челы говорят, что Раст всё равно лучше, а другие челы обсуждают все причины, по которым С++ впилить в кернел не получится, во всяком случае что бы с++ при этом оставался полезным.
Линус сам прекрасно осознаёт, что из-за своего ЧСВ и ощущения хозяйскости наговорил глупостей. Но из-за такого китайского концепта как "потеря лица" он не может признать, что говорил глупости.Разумеется, ядро давно необходимо перевести на C++ хотя-бы из-за его AST-безопасных inline-функций, улучшенной проверки типов в вызовах функций и compile-time вычислений (да, я знаю, они тяжёлые. Но в C++ есть модули, в них такие вычисления закешируются). Но необходимо ввести жёсткую конвенцию по написанию кода о том, что должно линковаться на уровне хэдеров, что - статически, а что - динамически, и разработать линтер. Без линтера тут никуда. За header-only нужно сразу от разработки отлучать с волчьим билетом.
Линус может сказать, что уже прошло много времени и язык существенно изменился в лучшую сторону, и всё. Ты как тогда не хотел понимать какие претензии были к с++, так сейчас не будешь разбираться что же изменилось в лучшую сторону.> Разумеется, ядро давно необходимо перевести на C++ хотя-бы из-за...
Кроме из-за ещё есть и аргументы против. Твоё выдёгивание только из-за' ничего не стоит
>Линус может сказать, что уже прошло много времени и язык существенно изменился в лучшую сторону, и всё.Он высказался не о языке. Он не подумав (зачем ему думать, он же диктатор-хозяин-барин и ядро - его собственность! правда потом спонсоры ему пояснили, who is who.) ляпнул, что недопуск C++ в ядро - это мера по недопуску в ядро программистов N-го сорта - программистов на C++. Если теперь он допустит в ядро программистов на C++, то ему придётся признавать 3 вещи:
1. что программисты на C++ - это не программисты N-го сорта
2. что Линус необоснованно из личной гордыни задел достоинство программистов на C++
3. что оттолкнув по мотивам личной гордыни и неприязни определённую группу программистов Линус проявил непрофессионализм и замедлил развитие проекта
Не знаю о каком именно высказывании говоришь, я видел только где в основном обсуждался ЯП
«C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.»
Linus Torvalds
> a lot of substandard programmers use itЛинус знатно потроллил. Никто ведь не заставлял принимать "a lot" на свой счёт.
> то ему придётся признавать 3 вещи:- что теперь программисты N-го сорта допущены в ядро.
Тут у Линуса осталось 3 варианта действий:
1. покаяться за вред, нанесённый проекту, и извиниться перед крестовиками. Будет больно и неприятно, но возможно тогда его оставят. Возможно... Не значит, что гарантированно. Тут главное - грамотно обосновать, почему смена руководства нанесёт проекту больше вреда, чем пользы. Если обоснует - то останется. Но лицо потеряет.
2. играть в несознанку и дожидаться, пока всех доставшего эгоиста прирудительно не снимут.
3. одобрить включение C++ в проект и попытаться замять историю с балабольством. Не выйдет - история широко известная, тут же найдутся те, кто включит аргумент "раз программисты на C++ плохие, то зачем ты их в ядро допустил, лидер ты наш Акелла? если они вдруг стали хорошими, хотя мы все знаем, что с обыдлением всё становится хуже, то как же так получилось, что твои слова противоречат реальности, может ты просто не хочешь признавать свою ответствееность за свой базар и свои действия? Зачем нам такой лидер?"Линус загнал себя в цугцванг сам своим безответственным поведением. На мой взгляд ему наиболее выгодно идти по пути 1. Но это сторонний взгляд, что в башке у Линуса - никто не знает.
Лол, а почему он не может сказать "раст уже в ядро добавили, зачем там третий язык?"
Более того, а за что каяться?
От добавления С++ ядро лучше бы не стало, по аналогии с Сишкой С89 сидели бы на С++98 до 2022 года(
Так что никаких смартпойнтеров и прочих даров цивилизации.Более того подозревая, что дудуки пилящие ядро начали бы писать в стиле "как умеют".
ИМХО тогда стало бы еще хуже.
>Лол, а почему он не может сказать "раст уже в ядро добавили, зачем там третий язык?"Какой третий? Весь сишный код фиксится до совместимости с clang++ и объявляется плюсовым.
>>Линус может сказать, что уже прошло много времени и язык существенно изменился
> Он высказался не о языке.Речь о c++ образца 2007г или ранних.
Вы сами то хотите на них писать? Ладно, это мелочь.А по существу. Тогда был подъем моды на объектное программированиее, причем где надо и ненадо, и даже там где это вредно.
И фраза про С++ "намного легче генерировать полную чушь" была не безосновательна.
Дай дураку инструмет, на котором он легко сделает говнокод, и он именно его и напишет.
Аналогична ситуация с количеством говнокода на Делфи и Питоне, и совсем не потому что языки плохи, а потому что позволяют навалить кучу по быстрому.
Разрешите поинтересоваться? Что именно подразумевает header only и почему это настолько плохо?
>Что именно подразумевает header onlyЛиба со сложным и/или большим кодом (а если код простой и небольшой, который вообще каждый может написать влёгкую за пару строчек - то нафига либа?), которую позиционируют как удобную для включения в проект за счёт того, что она представляет собой один или несколько несколько h-файлов, содержащих реализацию алгоритма. Сюда для целей "вон из профессии" не включаются небольшие header-only либы, предназначение которых есть compile-time вычисления. Пример такого хлама - nlohmann/json и CLI11. Такие либы действительно в некотором смысле удобно включать проект, путём простого копирования их в папку с хедерами и подключения хедера, или путём использования git-подмодуля.
>почему это настолько плохо?
a.cpp <- lib1.hpp
b.cpp <- lib1.hpp
c.cpp <- lib1.hppВ результате у нас тормоза при компиляции, и в каждый бинарь включена своя копия реализации. Это если a.cpp, b.cpp, c.cpp дают отдельные бинарники. Если всё линкуется в один бинарник, то вообще может быть ошибка линковки в случае криворукости разраба header-only либы. Если же он додумался сделать всё с inline, то ошибки линковки не будет, но копирование реализации и тормоза никуда не денутся. Любое изменение реализации либы приведёт к полной перекомпиляции проекта, а в случае отдельного хэдера с интерфейсом и линковке как OBJECT изменение реализации приведёт только к перекомпиляции файла с реализацией и перелинковке. Разумеется, при header-only либе ни о каком динамическом связывании, когда перелинкуется только бинарник либы, и версия либы вообще выбирается пользователем и не требует перекомпиляции зависящей от либы программы (необходимо для эффективной работы пакетного менеджера) даже и речи не идёт.
Программист свою программу должен писать так. чтобы пользователям этой пртграммы было удобно. Так как в опенсорсе программист зачастую сам пользователь, то тут это должно проявляться особенно. Но многие предпочитают срать на головы пользователям, даже не осознавая, что насрали на голову себе. Вон из профессии таких.
> и в каждый бинарь включена своя копия реализации.Подтверждением в виде дизассемблерного листинга не порадуете?
>> и в каждый бинарь включена своя копия реализации.
> Подтверждением в виде дизассемблерного листинга не порадуете?Не тормози, сникерсни! Если либа в .c/.cpp и ее отдельным .so сделали - все три проги поюзают один shared lib, если либу так собрать. Будет реюз кода либы.
А если это все было в header-only - опа, хидер .so не сделаешь! И все три получат свои приватные реализации фич которые они оттуда использовали и реюз кода не состоится. Это и есть обратная сторона header only. И интересно, чем тут дизассемблер поможет? Бывают конечно еще псевдолибы где кроме препроцессора и определений нихрена нет, но он видимо про полновесные хидеры с кодом.
А если у вас библиотека шаблонов, то методы с шаблонными параметрами тоже приходется в заголовочниках.
Шалонная часть STL - это тривиальные вещи, компилируемые в несколько процессорных инструкций. Нетривиальные находятся в libstdc++.so.
Большинство основных STL частей чисто шаблонные. Например, тот же std::map генерирует разный код для всех используемых комбинаций типов. В so-ке только темплейтнонезаисимые части и некоторые заранее сгенерированные шаблоны для типичных типов. Во время компиляции весь это код всё равно генерируется для каждого c++ исходника и дубликаты выкидываются только на стадии линковки
STL - это алгоритмы, итераторы и контейнеры, созданные Степановым и Ли. Для стандартной библиотеки лишь RTTI затруднительно реализовать как header-only, но оно и не надо в ядре. Все эти сказки про .so оставьте идеологам GPL, в ядро код и без них принимается только под этой лицензией.
>>> и в каждый бинарь включена своя копия реализации.
>> Подтверждением в виде дизассемблерного листинга не порадуете?
> Не тормози, сникерсни! Если либа в .c/.cpp и ее отдельным .so сделали
> - все три проги поюзают один shared lib, если либу так
> собрать. Будет реюз кода либы.Тормозят пока что эксперты и внедрители Си++ в Linux. У меня стандартная библиотека для ядра header-only была 15 лет назад.
> Тормозят пока что эксперты и внедрители Си++ в Linux. У меня стандартная
> библиотека для ядра header-only была 15 лет назад.И это все круто и офигенно - потому что что? С чисто практической точки зрения, если вы завтра перестанете существовать, вместе со своей либой - для меня изменится ну вот например что? Ах, ничего? Тогда и смысла передо мной рисоваться со всем этим - примерно ноль. Набивайте себе цену перед теми кому ваши поделия полезны, имхо. Это не я.
>> Тормозят пока что эксперты и внедрители Си++ в Linux. У меня стандартная
>> библиотека для ядра header-only была 15 лет назад.
> И это все круто и офигенно - потому что что?Потому что ты придумал тезис "круто и офигенно", что бы приписать его мне. В надежде на что?
> С чисто
> практической точки зрения, если вы завтра перестанете существовать, вместе со своей
> либой - для меня изменится ну вот например что? Ах, ничего?
> Тогда и смысла передо мной рисоваться со всем этим - примерно
> ноль. Набивайте себе цену перед теми кому ваши поделия полезны, имхо.
> Это не я."Я три дня гналась за вами, чтобы сказать, как вы мне безразличны!" (ц)
>Если всё линкуется в один бинарник, то вообще может быть ошибка линковкичудик не знал про #pragma once, но уже требует кого-то там вон из профессии :)
Э... Очевидно имелось ввиду именно линковка.Один файл компилируется в объектник с включенным заголовочником.
Другой файл генерируется объектник с включенным заголовочником.
Оба содержат одинаковые сгенерированные функции.
Теперь линкуем это в один бинарь и получаем ожидаемый нежданчик.
> За header-only нужно сразу от разработки отлучать с волчьим билетом.Взял и boost опозорил.
STL же, boost сама по себе помойка
> STL жеЛюбопытно, сколько из присутствующих видели библиотеку Степанова и Ли.
Покажи, посмотрим.
Если долго вглядываться в бездну, бездна начнет вглядываться в тебя.А вообще, всё зависит от прямоты рук.
# Непустых строк:
$ grep -c \. /usr/include/c++/*/vector
/usr/include/c++/13.2.1/vector:131 # GCC
/usr/include/c++/v1/vector:3045 # LLVM# Включений:
$ grep -c \#include /usr/include/c++/*/vector
/usr/include/c++/13.2.1/vector:10 # GCC
/usr/include/c++/v1/vector:50 # LLVM
$ pacman -Qo /usr/include/c++/*/
/usr/include/c++/13.2.1/ is owned by gcc 13.2.1-3
/usr/include/c++/v1/ is owned by libc++ 16.0.6-1
/usr/include/c++/v1/ is owned by libc++abi 16.0.6-1
Это не то.
> Разумеется, ядро давно необходимо перевести на C++ хотя-бы из-за его AST-безопасных inline-функций, улучшенной проверки типов в вызовах функций и compile-time вычисленийПочему бы это просто в C не добавить?
Давно есть. Человек просто поумничать хотел
Шаблонов нет, а compile-time вычисления есть?
C с этими добавлениями называется C++ :).
Похожими вопросами многие задавались ещё лет 15 назад, однако время прошло и Си как был бревном, так им и остался. С другой стороны, плюсы постепенно движутся куда нужно, но медленно. Скорее уж в плюсах появится ABI, чем в Си занесут новые фичи
Зачем переписывать на C++ чтобы потом пришлось переписывать на Rust умалчивается.
На rust переписывать не придётся. Его засунули в ядро чтобы шумные детишки наигрались молча с какой и потом остали от ядра сами
Тоже так считаю.
Раст - навсегда в ядре. Учитывая, сколько уве в сетевых подсистемах ведра на сишке, раст безалтернативен. А вот всякие алгоритмы сморт пойнтерс в плюсах далеко не каждый будет подключать, ибо плюсы и так громоздкие.
Ничего нигде не бывает навсегда, ты сам тут не навсегда. Как засунули, так и уберут. Тем более если говорить о языке в ядре, на котором пока что ничего важного нет кроме hello world. И если оно уже на Си и хорошо работает, значит вполне себе альтернативы есть - тот же Си. Учись рассуждать у мастера логики.> А вот всякие алгоритмы сморт пойнтерс в плюсах далеко не каждый будет подключать, ибо плюсы и так громоздкие.
Несёшь какую-то чушь, но можно поговорить об интеграции. Как уже заметили в обсуждении, c++ проще интегрируется в существующий код - точнее, интегируется, а rust - нет. У rust в лучшем случае какое-то время будет ниша штучных драйверов. Если рядом с rust появятся плюсы, то большинство разработчиков просто пойдёт по пути наименьшего сопротивления и выберет c++. А объяснить зачем нужно менять правильно приготовленные плюсы на rust уже намного сложнее.
Дело в том, что решают корпорации, они пишут ядро за свои деньги, и они выбрали раст. Платиновым спонсорам нужен раст, а плюсы им не нужны. Вот так вот...
Когда какой-нибудь Google начнёт массово релизить либы и продукты на rust вместо С++ и Go, тогда можно будет считать что выбрали. Пока что это местячковые потуги, как и со всеми остальными модными технологиями. И опять таки, ничего не бывает навсегда, особенно у корпораций: у них бабла много и не жалко выкинуть игрушку на помойку в любой момент
>Учитывая, сколько уве в сетевых подсистемах ведра на сишке, раст безалтернативен.А сколько на сегодня Раста в сетевой подсистеме ядра? Помоему, пока что хрен целых, хрен десятых.
Помимо политики была ещё одна причина - исключения в C++, хотя Линус тогда* не говорил, почему нельзя использовать плюсы без них.* https://lore.kernel.org/lkml/Pine.LNX.4.58.0401192241080.231.../
Линус и не развернул тему "fundamentally broken". В ядре NT возможно использовать исключения на IRQL PASSIVE_LEVEL, если очень захочется разрешить политикой проекта.
>В качестве минимальной упоминается использование спецификации C++14Не, нужно сразу 26 в редакции clangа на сегодняшний день брать. Потому что без ranges делать compile-time вычисления невесело. Хоть в шланге и нет ещё полноценных ranges, уже то что есть - очень полезно и убирает кучу того, что либо вручную приходилось держать в актуальном состоянии или скриптом генерировать (напр. индекс максимального элемента массива из фиксированных compile-time значений). magic_enum вообще офигенно полезная либа. Она хоть и header-only, но она не приводит к оверхеду на каждый включённый экземпляр, как если бы nlohmann json включили в один модуль, а потом во второй, и всё header-only. Другая офигенна полезная либа - это ctre.
вот честно... чем пользоваться этой синтаксической ахинеей проще написать в 5 строк скрипт на том же питоне для предвычислений
И огрести на ровном месте проблем, в частности тащить 2 реализации одного и того же на разных языках и гемороиться с интеграцией питоньего скрипта в систему сборки, чтобы каждый раз не пересобирало? Не, спасибо, я лучше ranges поюзаю.
> И огрести на ровном месте проблем, в частности тащить 2 реализации одного
> и того же на разных языках и гемороиться с интеграцией питоньего
> скрипта в систему сборки, чтобы каждый раз не пересобирало? Не, спасибо,
> я лучше ranges поюзаю.А потом через полгода выйдет новый пихон - и вообще сборочница сломается. Питонженетормозит и у него отличная совместимость между версиями. Вам что, впадлу чтоли код подправить?
Да, блин, знаете, когда начинает сыпаться с 9000 разных сторон - таки, впадлу!
В пакетах всё ещё можно поставить второй питон. Так что да, ничего не сломается. Конечно, для задач выше он не нужен, а именно - любая кодогенерация зло.
> В пакетах всё ещё можно поставить второй питон.Это в каких бы таких пакетах? Поддержку питона2 вынесли сами питоняши еще сколько там назад. Линуксные дистры и вынесли его - они быть святее папы римского не собираются, майнтайня софт за питоняш.
> Так что да, ничего не сломается. Конечно, для задач выше он не нужен, а именно
> - любая кодогенерация зло.Оно и видно что там не сломается. В дебиане 12 было аж 3000 чтоли багов на эту тему. Всего-то, блин. Они и задропали половину софта к хренам, им что, больше всех надо?!
Итерация свойственна человеку, кодогенерация божественна.
Засуньте ваш Шланг в... Ядрописатели требуют обязательность сборки GCC.
Шланг отстаёт от gcc по фичам языка, но опережает по строгости, статическому анализу, удобству использования и скорости результирующего кода. Тех же концептов до сих пор нет, и это создаёт проблемы для кода, который написан под gcc. Если шлангоспецифичные расширения не юзать - то gcc соберёт то, что собирается шлангом. Поэтому ориентироваться надо именно на собираемость шлангом.
Если разработчики ядра захотят обязательно эти концепты, то разработчики GCC пойдут навстречу. Почему нет?
в шланге нет концептов, в gcc они есть. Если задействовать код на концептах - то шлангом собираться не будет. А собирать лучше шлангом.
С чего вдруг лучше то?
См. рис. 1.
Как раз схожесть синтаксиса это скорее надостаток, потому что внешнее соходство вообще не означает что под капотом будет схожее поведение. Этакие "ложные друзья переводчика".
Так и си этого не гарантирует как и большинство высокоуровневых языков с >1 компиляторов.
Это гарантируют стандарты и Си, и Си++, а вот смешивание языков может привести к проблемам. Например, наверняка потребуют запретить перегрузку, что бы не вызвать у некоторых культурный шок.
Главные различия, которые следует запомнить:
В стандарте C++ нет Value Length Array (хотя GCC, Clang поддерживают их), приведение типов немного иное, ABI отлично.
В ядре тоже нету VLA. В стандаре C99 было, но потом, поняв ошибку, сделали это в следующем стандарте опциональным.
А в чём проблема VLA? Лучше с alloca и указателями для того же самого геморроиться и статическому анализатору палки в колёса ставить?
> А в чём проблема VLA? Лучше с alloca и указателями для того же самого
> геморроиться и статическому анализатору палки в колёса ставить?В том что...
1) Никогда не знаешь когда этот код навернется.
2) Способов узнать навернется ли он - нет.
3) В стандартах "C" нет слова "стэк" от слова вообще.
4) Поэтому вы в душе не и...те сколько его доступно и плохо ли arr[n] или прокатит.А теперь представьте что у вас по рандому будет грохаться ЯДРО по причине "переполнение стека". Как вам такая перспектива? Этот аспект конечно существует всегда но с именно VLA он вылезает наиболее зло и часто. Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000. При том вы даже узнать не можете ок ли такой n или нет. В отличие от мануальной аллокации где хотя-бы зввернут. А тут - сразу SIGSEGV какой бу, или что там. Круто, да?!
От переполнения стэка ни один код не защищён. И ни один код не защищён от исчерпания памяти.> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000.
При таком n, даже если всё в куче будет, на большинстве компов грохнется. И всё тут. И там и там надо ограничивать разрешённые значения N.
Всего лишь 100Мб, не грохнется. Тем более запрос через аллокатор никогда не приведёт к сваливаю
Тьфу, действительно мегабайт, перепутал с гигами.>Тем более запрос через аллокатор никогда не приведёт к сваливаю
С выделением на стеке тоже можно проверять, не случится ли переполнения. Но built-inа для этого в компиляторах нет.
Но почему-то проверок места на стеке нигде нет
> Всего лишь 100Мб, не грохнется.1) Ну попробуй так на AtMega какой-нибудь :). Правда, грохаться этот убогий не умеет чисто технически, ибо хардварных exceptions у авр нет как класса - но каким-нибудь интересным глюком в корчах в его фирмваре наверное воздастся.
2) Даже если это ОС - а ты уверен что сто мегов в вот именно стеке процесса таки дадут?
> Тем более запрос через аллокатор никогда не приведёт к сваливаю
Это не обязан быть запрос через аллокатор... одна из причин по которым операции на стеке быстрее операций в heap.
Фича стека в том что он аллоцируется и деаллоцируется автоматически, чаще всего с нехилым подпором железом. Антифича состоит в том что вы не можете узнать прокатило это или нет иначе как fault handler'ом "все пропало шеф!" в тыкву (или жесткими глюками если оно так не умело).
Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти? Речь про кучу, если вдруг проблемы с чтением> Фича стека в том что он аллоцируется и деаллоцируется автоматически, чаще всего с нехилым подпором железом.
Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны железа самая топорная
> Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти?А ты думал, штуки типа SIGSEGV из воздуха чтоли материализуется? А вот и хрен, это проц аппаратное исключение кинул на самом деле.
> Речь про кучу, если вдруг проблемы с чтением
В ней в конечном итоге тоже - память либо выделят, либо при левых поползновениях SIGSEGV будет. На самом деле в линухе при оверкоммите (т.е. по дефолту) это не сильно лучше стека ибо де факто аллокация "виртуальная" и ничем не обеспечена. Реальное выделение только при обращении. Связано с тем что многие программы заказывают намного больше памяти чем реально юзают, и это позволяет на доступном RAM нафоркать сильно больше процессов, соответственно.
Ценой некоей утратой предсказуемости - ибо ежели страница понадобилась - но ее нет - у вас *alloc вроде прокатил но это как бы и не обеспечено и нате-ка вам SIGSEGV. Но на внутренности кернела это не распостраняется.
> Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны
> железа самая топорнаяУ heap и такой нет - поэтому аллокации и деаллокации многократно тормознее.
> Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти?А ты думал, штуки типа SIGSEGV из воздуха чтоли материализуется? А вот и хрен, это проц аппаратное исключение кинул на самом деле.
> Речь про кучу, если вдруг проблемы с чтением
В ней в конечном итоге тоже - память либо выделят, либо при левых поползновениях SIGSEGV будет. На самом деле в линухе при оверкоммите (т.е. по дефолту) это не сильно лучше стека ибо де факто аллокация "виртуальная" и ничем не обеспечена. Реальное выделение только при обращении. Связано с тем что многие программы заказывают намного больше памяти чем реально юзают, и это позволяет на доступном RAM нафоркать сильно больше процессов, соответственно.
Ценой некоей утратой предсказуемости - ибо ежели страница понадобилась - но ее нет - у вас *alloc вроде прокатил но это как бы и не обеспечено и нате-ка вам SIGSEGV. Но на внутренности кернела это не распостраняется.
> Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны
> железа самая топорнаяУ heap и такой нет - поэтому аллокации и деаллокации многократно тормознее.
>> Всего лишь 100Мб, не грохнется.
> 1) Ну попробуй так на AtMega какой-нибудь :).Это и на AMD64 не работает.
> От переполнения стэка ни один код не защищён. И ни один код
> не защищён от исчерпания памяти.Если я статически пишу uint8_t arr[10]; я имею основания полагать что это будет работать даже на микроконтроллере с склерозом вместо памяти, и если этот код вообще запустился то скорее всего работает до упора.
Есди я динамически аллоцирую память и ее ен было - то там по крайней мере вернут ошибку и я могу ее прочекать. И что-то сделать по этому поводу.
Но если это будет
void func1 (uint32_t n) {
uint8_t arr[n]; // VLA!
// do something with arr[] here
}
...и вызывать func1(10); func1(100); func1(100500); ... то я вообще не знаю на каком n оно грохнется. И нет никаких способов это узнать, кроме как грохнувшись. Если *alloc еще фэйлить хотя-бы могут, то тут о фэйле узнаем только путем краха/системного факапа. Круто, да? Особенно в кернеле. Вы же будете очень рады что кернел в панику $%^нется без предупрежления, да?! Вместо фэйла внутренних операций, retry выделения памяти и прочих глупостей.>> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000.
> При таком n, даже если всё в куче будет, на большинстве компов грохнется.В случае динамической аллокации я как бы могу проверить успех операции. А тут сразу крах в репу, обработать нехватку памяти вообще совсем никак нельзя. И поскольку это рантайм параметр - получается код который очень ненадежный, скажем так, и может просто грубо навернуться если параметр неудачный. Без какой либо адекватной обработки этого вообще.
> И всё тут. И там и там надо ограничивать разрешённые значения N.
Просто крах без предупреждения, в рантайме, без возможности это обработать - может и ок для питоняш, но в системном яп - такое себе.
>Просто крах без предупреждения, в рантайме,кто сказал раст?
>Просто крах без предупреждения, в рантайме, без возможности это обработать - может и ок для питоняш, но в системном яп - такое себе.Сишечка не системная - также можно исчерпать стек, вызывая функции. Особенно если где-то там, в глубине вызовов, будет на стеке буфер, не VLA, но и не очень маленький - есть вероятность, что почти всегда из него будет использоваться пару байт, а иногда столько, что хватит для переполнения стека.
VLA, конечно, усугубляет, но сишечка сама по себе неадекватна задачам сиспрога например.
> Сишечка не системная -Да? А кто у нас тогда системный то? На сях что-то большая часть системщины, бутлоадеры, кернелы, фирмвари, либы, вот это все :). И у других - failure mode еще больше так то. В сях они простые и понятные как правило и их немного.
> также можно исчерпать стек, вызывая функции. Особенно если
> где-то там, в глубине вызовов, будет на стеке буфер, не VLA,
> но и не очень маленький -Одна из причин по которым жирное использование стека в функциях считается чем-то нехорошим, и кернел собирается с варнингом на размер стекфрейма, если что. По моему если у функции стек более кило - нате вам варнинг, во!
Кстати с современным компилером допустим сожрать стек рекурсией не так то просто, gcc допирает убрать сохранение-восстановление, копирование объекта и проч - и лианеризует рекурсивный вызов до чего-то типа цикла, с потреблением стека O(1) и временем выполнения O(n). И вот я вкатил рекурсию чтобы проверить работает ли мой детект stack overflow на мк и.. это не падает?! Ах ты ж блин, какой умный компилер! А чо, ассемблерщики, сможете оптимизнуть так же? :)
> есть вероятность, что почти всегда из него будет использоваться пару байт, а иногда
> столько, что хватит для переполнения стека.Поэтому...
1) Там где это важно чекают stack usage функций.
2) MISRA запрещает рекурсивные вызовы например, и системный софт должен намотать на ус эту идею и так не делать.> VLA, конечно, усугубляет, но сишечка сама по себе неадекватна задачам сиспрога например.
Ну вы то нам покажете что-то лучше? А то уж рекурсию можно на чем угодно, даже на асме, и тот кстати без оптимизаций - не будет линеаризовывать рекурсивный вызов до более плоского цикла и там все грохнется куда охотнее :)
В некоторых компиляторах есть builtin, позволяющий проверить наличие места на стеке. Где нет - его можно сделать. По-хорошему должен быть вариант alloca с проверкой. Но нет. По-хорошему должен быть VLA с проверкой на успех. Но Си - это не раст.
> В некоторых компиляторах есть builtin, позволяющий проверить наличие места на стеке. Где
> нет - его можно сделать. По-хорошему должен быть вариант alloca с
> проверкой. Но нет. По-хорошему должен быть VLA с проверкой на успех.Просто вопрос был почему VLA не рекомендуют в системщине. Ну вот потому. В сях вообще нет ни слова про "stack" в спеках. И, в принципе, VLA не обязан жить именно в стеке. Однако проблема того что память не бесконечная а какая-то реакция на ее нехватку невозможна - остается в любом случае.
> Но Си - это не раст.
Что-то мне подсказывает что у хруста других failure modes - на десяток си хватит. Они вон там свой panic любимый едва законопатили, меняя чуть не сорц компилера аж когда оказалось что в ядре panic это не оч хороший способ реакции на нехватку памяти. Там же и сказочные костыли с try-вариантами конструкций. Господи, какой бастардизированый гибрид сей с которыми боролись и чего-от из плюсоты, все хучшее от обоих миров - в один яп?!
>VLA не обязан жить именно в стекеЛокальные переменные живут в стеке. VLA в принципе может жить где угодно, но нужен он именно на стеке.
>Они вон там свой panic любимый едва законопатили
panic!ует код тогда, когда не обработана ошибка, в частности наиболее распространённый случай - когда на std::result вызывают unwrap. В системном кодe необработанных ошибок быть не должно - это путь либо к уязвимости, либо к kernel panic. rust это просто подсвечивает.
> Локальные переменные живут в стеке. VLA в принципе может жить где угодно,
> но нужен он именно на стеке.Читайте стандарты си. Там вообще нет упоминания стека, никак и нигде. То что конкретные реализации решили делать так - ну, окей, однако если кто-то сделает это иначе, он - в своем праве. Это implementation defined хрень. Вы не можете уповать на это при написании программы. Поэтому если кто-то вывесит VLA через heap или что там у него - а они в своем праве были.
У си довольно интересные стандарты - и далеко не всегда это именно похвала комитету. Спихнувшему более 9000 своих проблем на других.
>>Они вон там свой panic любимый едва законопатили
> panic!ует код тогда, когда не обработана ошибка,Я так понимаю что паника была дефолтовой реакцией на неуспешные потуги аллокации крупных массивообразных штук, box чтоли, они там называются.
И дошли они в результате до костылирования с тем же названием с довеском try отличающим по поведению эту сущность. Я честно говоря не понял почему все так костыльно и почему они так героически заборов дракона вдруг заметили что без него что-то стало хреново - и немедленно превратились в еще более стремного на вид дракона. Пппростите, а чем ЭТО отличалось от *alloc и сотоварищи? Можне мне этот высококонцептуальный пируэт объяснить? В результате маркетинг оказался, как бы это, не совсем правдой. Ибо в итоге пришли к тому с чем боролись. Фэспалм.
> в частности наиболее распространённый случай - когда на std::result вызывают unwrap.
А в кернеле и вообще embedded, etc вот именно тот std вообще будет? Ибо врядли дефолтовый, из супер-дупер-либы на все оказии делает именно то что уместно делать в недрах кернела. И скорее всего подразумевает работу в нормальной ос. А что если этой нормальной ос еще нет?!
> В системном кодe необработанных ошибок быть не должно - это путь либо к уязвимости,
> либо к kernel panic. rust это просто подсвечивает.И я не понимаю почему в wannabe-системном яп потребовались вон те костылищи с отдельными сущностями. Появившимися вот именно после потуг в кернел влезть. И там аж компилер постоянно патчат под это все.
Представьте себе что для написания кернела требовалось бы постоянно патчить GCC. Вы бы вообще смогли кернел написать в результате? Да и Торвальдс, пожалуй, тоже.
>Если я статически пишу uint8_t arr[10]; я имею основания полагать что это будет работать даже на микроконтроллере с склерозом вместо памяти, и если этот код вообще запустился то скорее всего работает до упора.Конечно, не будет. Во всех тестах в массив будут записаны 1-3 байта и они ничего не поймают, в продакшоне наконец-то в этот массив запишут из сети 10 байт, запись затрет канарейки и структуры планировщика FreeRTOS, лежащие прямо за концом стека, задача вместо паники зависнет и девайс ребутнется по ватчдогу.
> Конечно, не будет. Во всех тестах в массив будут записаны 1-3 байта
> и они ничего не поймают, в продакшоне наконец-то в этот массив
> запишут из сети 10 байт, запись затрет канарейки и структуры планировщика
> FreeRTOS, лежащие прямо за концом стека, задача вместо паники зависнет и
> девайс ребутнется по ватчдогу.Это всякие системные ламеры, обложивщиеся RTOS не поймают, у них "тойота" и получается. А я посмотрел на тойоту. Подумал. И теперь - даже на Cortex-M без MPU научился делать лэйаут RAM где переполнение стека хоть на байт немедленно эскалирует в HARD FAULT (нет, не MPU, его нет), который не заметить очень сложно. Ибо самый суровый эксепшн на все ядро, выбивающий все кроме NMI нафиг. И теперь мы займемся реакцией на вот это, зная что в системе Ж, ждать вачдог не обязательно.
...а еще я таки сделал обработчикам приватный стек, так что они еще и что-то сделать могут. Даже если основной стек кончился. У ARM для этого довольно клевая фича есть, отдельный стек для handlers.
...кроме того я заинструментил немного наколенный, но весьма забавный анализ worst-case рантайм потребления стека. Идея проста: заполняем раму паттерном в startup, пускаем фирмвару работать, если знаем самые ресурсоемкие ветки, прозваниваем их. Через некоторое время просим дамп оперативы, смотрим на регион стека, делаем выводы о runtime margins.
Главное, чтобы у тебя этот суровый(r) эксепшн(tm) не произошёл во время полёта на обоих модулях - основном и запасном...
А как он может не произойти, если искандер-5 заходит на цель с перегрузкой в 30 раз больше, чем искандер-4 (и памяти для искандер-4 строго говоря не хватало, но с учетом ограничений ТТХ кулибины как-то зарелизились)???
> Главное, чтобы у тебя этот суровый(r) эксепшн(tm) не произошёл во время полёта
> на обоих модулях - основном и запасном...Если это важно - это решается другими методами. См. как это кажется, боинг сделал. Две тимы писали 2 разные программы, запущенные на 2 разных процах, ... вот как раз чтобы вероятность этого была ниже плинтуса.
...у меня, к счастью, не настолько крутые требования, и все же мне охота залезть в довольно требовательные применения, где факап управления может чего-нибудь пожечь и проч, что как бы не прикольно. В этом смысле fail fast с приведением системы в безоапсное состояние лучше чем ждать вачдога в абы каком состоянии, делая хзчто.
Не гидравлический пресс надеюсь?
А то fail fast может в fall fast перейти :D
Мне у некоторых софтсвитчей вот этот fail fast нравится.
Да пусть оно лучше сессию дропнет, наплюёт херни в логи, или выдаст в сессию шум океанов марса.
Нежели все 100500 звонков разом лягут.
> Мне у некоторых софтсвитчей вот этот fail fast нравится.
> Да пусть оно лучше сессию дропнет, наплюёт херни в логи, или выдаст
> в сессию шум океанов марса.
> Нежели все 100500 звонков разом лягут.Софт свич несколько отличается от печатки с силовухой, допустим. Одно дело по превышению тока сразу в safe state свалить, и совсем другое - подождать вачдога, который там дескать может ребутнет, но до того момента - силовые ключи - и половина платы - правратятся в чуть ли не кусок плазмы уже, и тогда х... толку с вачдога?! Даже если проц и перезагрузится - то чего? В этот момнет уже поздняк на превышение тока реагировать и что-то выключать.
Если у вас на плате нет защиты от превышения тока кроме софта - я вам очень сочувствую, и да, можно название, чтобы это не брать никогда?
> Если у вас на плате нет защиты от превышения тока кроме софтаПо законам Мерфи - устройство порой сгорает первым, защитив предохранитель ;)
И FYI, предохранитель нельзя брать впритык - иначе периодически его будет выбивать "без причины". А еще пусковые кратковременные режимы бывают куда тяжелее крейсерских. Это не значит что они вдолгую безопасны. Работает этот мир так. Но чтобы об этом знать надо немного поинженерить. Так что лишняя линия защиты никому не мешала еще.
Алсо вылетевший предохранитель это прерывание сервиса, доволно надолго. Self restart после устранения проблемного условия - лучше чем трах с сменой предохранителя.
По причинам выше - быстродействующий предохранитель, "на грани" - не захочется. Ибо придется постоянно заниматься его заменой. А то что медленный обгонит дестрой ключа крутым перегрузом... ну вот не факт. И вот там МК, которому микросекунды дом родной, имеет шансы зарубить проблемное условие ДО того как это станет проблемой. При том он в отличие от глупого предохранителя в курсе, startup это или авария, допустимо ли столько времени, или уже перебор, и так далее. И можно вон те неудачные соотношения несколько обойти.
> - я вам очень сочувствую, и да, можно название, чтобы это
> не брать никогда?...сказал тип, стесняющийся уточнить название своего прова за отношение в ipv6 :). Впрочем можете не париться - я масспродом не занимаюсь и ваши шансы купить сие весьма низкие.
А ваш софт умеет думать, пока МК дымится вместе с платой? :)
Почему? Потому что по законам Мерфи первым сдохнут датчики для вашего софта.
Как я понял твои ответы.
- Если мы используем массив со статическим временем жизни, то мы надеемся, что стек не переполнится.
- Если мы используем обычный массив на стеке, то мы надеемся, что стек не переполнится.
- Если мы используем VLA-массив, то много энергично говорим и надеемся, что стек не переполнится.
> Как я понял твои ответы.
> - Если мы используем массив со статическим временем жизни, то мы надеемся,
> что стек не переполнится.И мы можем более адекватно эту идею проверить. Частично даже в компилтайме, смотрением на размер стекфрейма.
> - Если мы используем обычный массив на стеке, то мы надеемся, что
> стек не переполнится.Это допущение опять же более просто проверить, если нет рекурсии.
> - Если мы используем VLA-массив, то много энергично говорим и надеемся, что
> стек не переполнится.VLA - это еще хуже чем динамическая аллокация памяти. Потому что это та же динамическая аллокация памяти - но еще и без возможности сделать что-либо осмысленное, и без известного на момент компила upper bound что вообще совсем рубит любой компилтайм анализ этого. Вы вообще не знаете worst case размер стекфрейма этой функции теперь.
И таки си - мультипарадигменный. Если ну вот капец как надо - можно сделать "fully static allocation", распределив вообще все статически. Ну то-есть все переменные сделать либо static в функциях, либо глобальными. И тогда - если все выделено сразу на старте, оно не может закончиться вот хоть как. Единственное что остается это глубина вложенных вызовов функций. Это неоптимально по ресурсам - потому что все и вся выделено всегда. Зато гарантии лучше. Вот и выбирайте.
Примерно такой же tradeoff существует и в оверкоммите памяти в случае линуха. Можете не оверкомитить и обеспечивать все выделеные адреса физической оперативой. Но тогда сможете намного меньше программ на том же RAM запускать.
Я почему шучу про "много энергично говорим" - потому что идеи assert'ов для размера VLA, тестирования худшего случая отметаются как немыслимые и тебя куда-то совсем понесло. "Еще хуже чем динамическая аллокация памяти" - вот, фрагментация кучи уже лучше, чем VLA. Даже не "так же плоха", как написала бы MISRA, а хуже.> Это неоптимально по ресурсам - потому что все и вся выделено всегда
В принципе на этот случай есть union'ы, но с ними придётся следить не за стеком, а за тем, чтобы не было обращений к неактивным полям и чтобы инициализация активного поля нигде не пропускалась.
> Я почему шучу про "много энергично говорим" - потому что идеи assert'ов
> для размера VLA, тестирования худшего случая отметаются как немыслимыеНе то что немыслимые - а "еще хуже чем динамическая аллокация". Ибо еще менее defined и еще меньше возможностей для корректной реакции.
А что должен кернел сделать по assertion failed? В панику брякнуться? Ну, зашибись реакция, конечно. Юзерям понравится. Retry выделения в этой парадигме вообще не получится (смысл повторять тот же assertion?!), вернуть caller'у ошибку - наверное не assert тоже было. И получается как вон то - только еще хуже, ибо грабель больше и контроля над ручкой нет, грабля автоматически подпрыгивает и лупит в лоб всех кто проходит мимо.
> и тебя куда-то совсем понесло. "Еще хуже чем динамическая аллокация памяти" -
> вот, фрагментация кучи уже лучше, чем VLA.Внезапные крахи и почти полная невозможность их адекватного парирования спускают си до уровня питоняш и нафиг нам такой си вперся вообще?
> В принципе на этот случай есть union'ы, но с ними придётся следить
> не за стеком, а за тем, чтобы не было обращений к
> неактивным полям и чтобы инициализация активного поля нигде не пропускалась.Я даже примерно так (изредка и немного) делаю - но при этом желательно сделать некий interlock ресурса, для проверки использования, иначе так окажется что мы тут храбро юзали массив - а вон там сетапнули DMA, забыли про это, все счастливо пахало... пока DMA не добрался до нас и не протер все к хренам другими данными... а мы не понимаем - откуда, блин, это вообще вот так?!
> От переполнения стэка ни один код не защищён.Дожили. А вот ядро Windows NT - защищено. Потому что там стек не используют и таких как ты не подпускают.
Для особо одарённых, кто судит по себе и считает это троллингом: https://learn.microsoft.com/en-us/windows-hardware/drivers/k...
> А вот ядро Windows NT - защищено. Потому что там стек не используют и таких как ты не подпускают.
> Для особо одарённых, кто судит по себе и считает это троллингом: https://learn.microsoft.com/en-us/windows-hardware/drivers/k...И по ссылке написано, дословно, "под стэк выделено суммарно три страницы, так старайтесь делать дерево вызовов плоским, а рекурсивным вызовам поставьте ограничитель, потому что переполнение приведёт к фатальной ошибке системы".
>> А вот ядро Windows NT - защищено. Потому что там стек не используют и таких как ты не подпускают.
>> Для особо одарённых, кто судит по себе и считает это троллингом: https://learn.microsoft.com/en-us/windows-hardware/drivers/k...
> И по ссылке написано, дословно, "под стэк выделено суммарно три страницы, так
> старайтесь делать дерево вызовов плоским, а рекурсивным вызовам поставьте ограничитель,
> потому что переполнение приведёт к фатальной ошибке системы".Надо перевести на понятный? Стек крайне осторожно используется для хранения адресов возврата, ни слова про размещение там array, а тем более variable length.
Боюсь, что это ты не понял. Данная статья просто предостерегает разработчиков о том, что стек имеет весьма ограниченный размер, и даёт указания, как с ним следует работать. Ни о какой защите речи не ведётся. Это самый обычный стек.
Очевидно, это ты не понял смысл "таких ... не подпускают". Защита стека в Windows выполняется административными методами. И вот таких, кто ничего не написал под ядро, но чему-то учит относительно стека, там не подпускают тоже.
> Защита стека в Windows выполняется административными методами.Ух едрить как же всё запущено. Ну, с тем же успехом можно сказать, что код защищён от багов, потому что все MR-ы проходят обязательный code review. =)
Зачёт, нуби. Завести что ли где-нибудь на опеннете мемориз с глупостями... =)
>> Защита стека в Windows выполняется административными методами.
> Ух едрить как же всё запущено. Ну, с тем же успехом можно
> сказать, что код защищён от багов, потому что все MR-ы проходят
> обязательный code review. =)
> Зачёт, нуби. Завести что ли где-нибудь на опеннете мемориз с глупостями... =)Я знаю, что некоторые умело подменяют тезис с целью превзойти собеседника.
Вот только я не спорю, а сообщаю факт: вопросом про стек отсеивают всех умельцев работать лишь языком, в самом начале собеседования.
Размер стека можно задать каким нужно, вызвав соответствующую функцию. Это он по-умолчанию такой, потому что "12 килобайт хватит каждому". А кому не хватит - тот может затребовать больший.
> Размер стека можно задать каким нужно, вызвав соответствующую функцию.Формулировка некорректна. Можно _попробовать_ задать размер.
KeExpandKernelStackAndCallout
...
Returns success if the stack allocation is successful and the callout has been called. Otherwise, returns a failure status.> Это он по-умолчанию
> такой, потому что "12 килобайт хватит каждому". А кому не хватит
> - тот может затребовать больший.А кому в итоге не хватит?
Running out of kernel stack space causes a fatal system error. Therefore, it is better for a driver to allocate system-space memory than to run out of kernel stack space.
Если даже до этого не дочитали, то до описания KeExpandKernelStackAndCallout и понимания, зачем она вообще нужна, тем более не дошло.
> не защищён от исчерпания памяти.
>> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000.Хорошо, n=55666, но память процесса переполнена.
Или переполнена иным, более естественным способом.Что сделает ПО безопасном языке? Да точно так же грохнется,толко некролог подробнее выдаст, но это не точно.
Во встраиваемом ПО можно генерировать прерывания, при попытке выхода за границы области стека или его части, но не везде это делается очевидным и удобным способом.
Но и тут, по исчерпании памяти можно только перезапустить ПО, максимум с частичным сохранением состояния.
>> не защищён от исчерпания памяти.
>>> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000.
> Хорошо, n=55666, но память процесса переполнена.
> Или переполнена иным, более естественным способом.Я знаю что сделает нормальный системщик.
1) Запретит такую конструкцию если без нее можно обойтись.
2) Если нельзя, аллоцирует динамически - и проверит успех. А если неуспех, что-то сделает по этому поводу, от вываливания из программы до retry через некоторое время в надежде что память освободилась (так например некоторые БД делают, вместо того чтобы сразу завернуть, предпринимают несколько попыток, и сдаются только если за энное время не полегчало).> Во встраиваемом ПО можно генерировать прерывания, при попытке выхода за границы области
> стека или его части,В обычных программах примерно то же самое известно как какой-нибудь SIGSEGV и в POSIX эта модель по сути и остается. Проц получает исключение от MMU, и кернел в общем то гейтует его программе как сигнал SIGSEGV. Дефолтный хэндлер просто вырубает прогу, но можно и свой прицепить и сделать что-то более продвинутое.
Однако если вам приехал fault handler по причине "стек кончился" - ну, э, удачи в корректном возобновлени работы программы. Ведь стека уже не хватило, состояние в "основном потоке" в общем то уже урыто. Корректного гарантированого способа вернуться их хэндлера в основную тушку на этот момент уже не существует в общем случае.
> Но и тут, по исчерпании памяти можно только перезапустить ПО, максимум с
> частичным сохранением состояния.Окончание стека это весьма грубый системный факап. Ведуший к очень голимым последствиям. Тойота проверяла. Получив class action lawsuit от злющих родственников усопших водил и тех кому острые ощущения от вождения не понравились.
> А в чём проблема VLA? Лучше с alloca и указателями для того
> же самого геморроиться и статическому анализатору палки в колёса ставить?Проблема в том, что это ядро. Вот скажи, какой там размер стека?
Ну если хруст завозят, то и православные плюсики должны завезти.
Немного не так.
Зашкварился на rust? Всё, теперь c++ отказать — не по понятиям. (Далее, остальные в очередь.)
</trollFace>
Это уже помойка будет какая-то.
Плюсы очень нужны в ядре, потому что поддержка модулей в Си даже не планируется, а хедеры очень сильно замедляют компиляцию.
Модули в рабочем состоянии пока что только в компиляторе от микрософта
В шланге давно в рабочем состоянии. И в CMake с недавнего времени. Но ядро Linux продолжает жрать makefile-кактус вместо CMake+Ninja.
CMake сам по себе кактус. И у тебя вообще хватает инженерного интеллекта, чтобы догадаться, что система сборки, полностью заточенная под юзерспейс, для ядра не подходит?
Сфигали не подходит для ядра, если для сборки под голые микроконтроллеры без разделения на юзерспейс и кернелспейс подходит?
Если не подходит, то это же ещё не означает, что не найдутся упоротоые, которые будут готовить из буханки белого троллейбус. Ну и сравнил, конечно, гогнокод под голый контроллер с развесистым ядром.
Но, но ведь троллейбус делается из буханки ржаного!
В любом случае чистые make файлы это уже анахронизм (кроме некрофагов из ядра)))
модули - проприетарный рак от майкрософт. хидеры ничего не замедляют, если мозгами хоть иногда пользоваться, что в случае майкрософт невозможно
Тогда вам стоит для начала поработать с большими проектами
Насколько большими? Сколько строк?
Настолько, что какой-нибудь sloccount не посчитает за разумное время
так вы не делайта свои "большие" проекты в одну портянку....
А модули в Python, D и ещё много где, тоже Microsoft ввела?
header-only библиотеки конечно можно написать так, чтобы они замедляли компиляцию. но так обстоит дело с чем угодно почти. так что просто нужно писать грамотно и ничего замедлятся не будет.такая байка, что компиляция будет очень долгой из-за ho пошла еще со времен кода в духе александреску. ситуация уже давно изменилась а байка осталась.
Это не байка. Ты на своей шкуре это сможешь заценить, подключив в программу CLI11.
Это не байка. Погугли патчи ядра от Инго Молнара.
Наконец-то С++! Архаика Си - это конечно круто, но технологии идут вперёд!
Внедрение плюсов - такой себе шаг вперед
Си плюс-плюс - это шаг назад.
Пусть пихают и раст и зиг и сипипи сразу. И вейланд с системдой тоже сразу в ядро. Ресукликс-Биникс!
И Carbon, и VLang - тоже !
Cabron.
Cartoon
а вот VLang мысль и в самом деле интересная. Но, но что там с архитектурами, отличными от x86?
Он вроде в С компилируется, значит считай поддерживает считай что все. В отличии кстати от очень ограниченного набора платформ у Rust.
Не забывая про Zig и Seed (ElenaLang -тоже неплохо )) )
Marusya на подходе :)
Сначала Алиса
> Сначала Алисатакими темпами не видать нам Katyusha :)
Seed это вот этот https://ru.wikipedia.org/wiki/Seed7 ?
> Rust
> C++Бедный Linux, как же упорно туда всякую гадость пихают...
Если плюсы таки завезут, то rust там быстро сдохнет
Вместе с Си и ядром целиком
Это тебе так кажется. Раст "пихают" не потому, что "фанаты", а потому, что на то есть объективные причины. Те самые причины, по которым пихают его, а не С++. Это не вопрос того, что кому больше нравится. Это вопрос сугубо технический. И раст чисто по техническим причинам оставляет С++ далеко позади.
Да, конечно, не потому что 'фанаты'. Давай посмотрим на объективные факты. Основа современного софтверного мира прекрасно существуют вообще на Си, даже не на плюсах. Прекрсно существует несмотря на все проблемы с Си. И rust в этом существовании ничего не может радикально улучшить. А именно не снизит существенно человеко-часы на разработку, ни увеличит кол-во решаемых проблем вообще. Т.е. проблема будущего развития ядра никак не упирается в проблемы Си в ядре.Технические вопросы это можно ли, и как, занести c++/rust в ядро. А нужно ли уже вопрос экономический если рассматривать в объективной плоскости. Оценок, естественно, профита от внедрения никто не делает т.к. это сложно и в реальности вопрос сводится в экспертную плоскость на уровень личных мнений.
Если сравнение Си против rust более-менее можно увести в пользу rust, то с псюсами так не получится. Потому что плюсы это сбалансированный ЯП, а rust смещает внимание только на решение одной пробемы и заносит много мусорных решений из функциональщины вроде всё в ЯП выражения вместо высказываний. Выбор rust именно фетиш на единственную фичу и вера в её полезность, тут и близко нет никакого объективного технического выбора.
В таком выборе в приниципе нет ничего плохого. Плохое это, будущи гуманитарием, пробовать замаскировать свои предпочтения под некий объективный и технический выбор.
Кресты это нехорошо. Одни и те же ошибки ошибки при завышенном чсв плюсовиковНе могу придумать никакой отрасли (кроме игр) где я бы согласился на плюсах проект начинать
Поддерживаю данное начинание!
Это ядро уничтожит энтропия и тогда GNU Hurd всех победит. Осталось подождать ещё лет 10.
Хм, я от с/с++ отошел лет так 15 назад. Но вроде наибольшей проблемой в применении плюсов была бинарная несовместимость между разными компиляторами. Тогда как в чистом с можно было линковаться между разными компиляторами, потому что есть бинарная совместимость. Для расширений питона это вроде до сих пор актуально. Не будет ли из-за этого проблем с ядром? Гарантировать что все блобы в ядре и сторонние модули будут скомпилированы одним компилятором никто не может.
Ведро беспокоит что-либо, кроме gcc?
А разве с СИ не так же?
Пришлось делать гну-тые расширения, чтобы собирать ядро.
>Но вроде наибольшей проблемой в применении плюсов была бинарная несовместимость между разными компиляторами.Я до сих пор проигрываю с того, что они даже схему manglingа стандартизировать не могут.
Да чё там думать, пусть берут эту схему из g++. Кстати, кто-то как-то приводил документ из недр Мелкомягких, где они это и предлагали сделать на уровне языкового стандарта. Сейчас не могу найти ту ссылку.
Зачем конкретному ядру бинарная совместимость? Эту версию ядра или другую можно полностью с модулями пересобрать другой версией компилятора. Стороннние модули тоже можно пересобрать нужной версией.
Про какие блобы речь? Если загружаемые прошивки в девайсы, то пофиг, чем оно там для них собиралось. Оно с кодом ядра линковаться и не будет. Если блободрайверы, так это же хорошо. Мейнтейнеры ядра и так всеми силами борются с блободрайверами. Это им только в помощь. Пусть вендоры приучаются выпускать открытые драйвера.
Например, какая-нибудь nvidia тебе поставляет драйвер готовым модулем
Скоро ядро перепишет ИИ. В бинарных кодах сразу.
Машинный код
Пусть хотя бы драйвер напишет рабочий. А потом сможет в нем баг поправить.
ИИ пока что даже простой код генерировать не научился. Если не считать измусоленные факторилы с фибонначи. Куда ему до ядра?
Это не тот самый разраб из Интела, который прислал такой пачт, который даже не скомпилился?
И бедяге пришлось выражаться %^!@$%, тк высказаться прямо он уже не может(((And why the %^!@$% does a header file include a C file? That's wrong
regardless of this bug.
https://lore.kernel.org/dri-devel/CAHk-=wgPJttFz8yrdpPTN-ypM.../
Ну наконец-то об этом заговорили!
давно пора.
А я согласен на плюсы в ядре. Благодаря изменениям под встраиваемые системы там теперь можно исключения не использовать. И более строгая проверка типов чем в С. Плюс, выразительнее языковые конструкции можно делать.
А Раст - это просто попытка корпорастов под себя "поляну" подмять. Они же, наверняка, весь это "хайп" вокруг языка и разводят за бабло. Чтобы потом одним прекрасным утром поставить специальный блоб (как пример) в зависимостях и никто никуда уже не слезет. И с упорностью осла лезут в проект в который их никто не звал, вместо того, чтобы свой делать и показать как надо. Инфоцыгане.У C++ хотя бы комитет стандартизации существует. Да, он тоже многими корпорастами спонсируется, но там тяжелее свою волю навязывать. Приходится уже договариваться.
А каких, собственно, корпорастов?
Тех, которые GCC разрабатывают?
В гугле забанили?
https://isocpp.org/std/the-committee
Одни белые лица и в основном мужики, никакого диверсити.
Ты лучше посмотри где они работают)
Сплошные майкрософты, гуглы и прочие корпорации.
Так что, "что они скажут - так и будет".
> Плюс, выразительнее языковые конструкции можно делать.С другой стороны понаделают "выразительных конструкций", а потом разгребать. В большом проекте с большим кол-вом участников чем прямолинейнее конструкции, тем лучше имхо.
Вот, ради интереса, поробуйте объяснить кому-нибудь (да хоть себе) как в Ядре списки и работа с ними сделаны. (это к "чем прямолинейнее конструкции, тем лучше").
вы точно программист ?
Ну тут надвое сказано... Что именно "разгребать"?? ООП для того и придумали, что сложность современных систем на порядки выше старых юниксовых пародий. Соотв. без хорошей декомпозиции и абстракций ничего надёжного ты не напишешь.Другой вопрос, что с ЛЮБЫМ ООП языком придётся тянуть и его рантайм (который просто нельзя выкинуть). И как рантайм одного модуля "дружить" с остальными? (включая ядерный) Вот где засада. На одном хелловорлде рантайм прекрасно работает. Но в сложной модульной системе - большой вопрос.
> ООП для того и придумали,
> что сложность современных систем на порядки выше старых юниксовых пародий. Соотв.
> без хорошей декомпозиции и абстракций ничего надёжного ты не напишешь.А причем тут ООП? Хорошую декомпозицию и абстракцию можно сделать без него: lisp и erlang как пример.
> в случае языка С++ можно по частям переводить код с языка C, так как С-код можно компилировать как C++скорее потому, что с++ - надстройка над с
> один из ключевых разработчиков ядра в компании Intel
того самого intel, который патчи даже не компиляет перед отправкой?
> скорее потому, что с++ - надстройка над сПожалуйста, никогда не пишите код на C++. Вот из-за таких сишников, пищущих на "C с классами" у C++ плохая репутация.
Давайте классы на GовноObject делать, так определённо лучше!
как раз наоборот - современный ++ выглядит порой как несто среднее между растом и brainfuck.
>> скорее потому, что с++ - надстройка над с
> Пожалуйста, никогда не пишите код на C++. Вот из-за таких сишников, пищущих
> на "C с классами" у C++ плохая репутация.Не знаю насчёт этого, но от неполной совместимости с C у него репутация портится. Например, type punning через union зачем-то сделали UB. На практике этот приём в плюсах широко используется и если он вдруг где-то сломается, это будет проблемой скорее компиляторописателей, чем пользователей компилятора.
Реальный результат изменения - плюсовики бегают и стращают друг друга неопределённым поведением на смех растовикам. Вот сейчас в компиляторах сломать не рискуют, а через 50 лет? То-то же! Но это настолько удобный приём, что UB здесь как первородный грех. Но программирование - не религия, чтобы заниматься догматическим внушением вины перед Комитетом. Может, ему лучше убрать из текста бесполезный де-факто несуществующий UB?
Потом все равно на Carbon переписывать.
А вот кстати про Carbon почти никто не пишет, а он развивается просто бешеными темпами. Так что может быть и не шутка.
> почти никто не пишет, а он развивается просто бешеными темпамиПонятное дело, что если обратную совместимость не блюсти, то можно все менять как хочешь. Другой вопрос: вот раст в ядро завезут, должен же быть фриз на версию компилятора, чтобы каждый раз новое ядро не пересобирать новой версией компилятора раста.
И карго почти наверняка будет запрещено, а ведь это считай центральная фича языка.
В методичке написано, что это не часть языка и вы можете жить и без него. Но: таки да, r... тащат в ядро, чтобы оно паровозиком для cargo послужило. Без cargo цели достигнуты не будут.
> а ведь это считай центральная фича языка.Агаблин, обеспечивает вендорлок на гугл, амазон и майкрософт.
У меня поменялось мнение по поводу Carbon: профитнее лучше изучить сами плюсы, чем внедрять левый язык. В C++ УЖЕ есть все инструменты чтобы писать простой и безопасный код, нужно лишь научиться и разработать хорошие гайдлайны для последователей, в этом значительно больше смысла, чем разработка очередного языка, как будто сейчас мало языков.
Гугель говорил, что Carbon будет собирать и код писанный для C++.
Подскажите, это начало конца или второе рождение?
Время переходить на NetBSD.
Если и переходить на то семейство, то уж на Стрекозу.
Почему не QNX? Minix? Да даже BeOS была бы куда лучшей альтернативой!
Это метастазы.
Это конвульсии трупа :) Фактически уже понятно - как только "добрый диктатор" сдохнет, начнётся полный коллапс (не по этой причине, а тупо из-за бестолкового, монолитного, плохо спроектированного ведра). И на каком языке писать ведро вопрос уже стоять даже не будет.
Я за ядро на Java. Заколебали уже. Там тоже синтаксис аналогичный. И вообще все есть интернет. У них вон 8-я версия много лет в продакшене и жабомашина может запускать разные версии когда надо. Чего к плюсам привязались?
Солянка - так солянка.
с gc что будем делать?
А JVM под чем крутить?
Под lisp-машиной
А Lisp-машину на чём? Гусары, молчать!
Так она уже машина. Или не знаешь что это такое? Тогда википедия в помощь
Пока это только умозрительная машина.Которую можно вертеть только на ...
> Я за ядро на Java.Только на java-процессоре.
А Lisp-машину на чём? Гусары, молчать!
на эмуляторе поверх явапроцессора
Пока линуксом управляет один единственный до*боеб, способный забаррикадироваться в своих 80-ых, и единолично принимающий судьбоносные решения, вашему красноглазому сообществу никакой прогресс не грозит.
Все вы так и будете сидеть в этом ~1%-ом дер*ме, и извергать желчь в сторону виндовс и прочих маков.
Что бывает с модными-молодежными компаниями, лезущими поперед батьки в пекло, можно увидеть на примере Мозиллы.
> Что бывает с модными-молодежными компаниями, лезущими поперед батьки в пекло, можно увидеть
> на примере Мозиллы.Есть пример лучще - Fuchsia и ее "вот, мы, ща, на десктопы, столица миоа - в нью-васюки!". Вон там в соседней новости, где гранд-план по захвату мира кажется немного обломался.
>Все вы так и будете сидеть в этом ~1%-ом дер*ме, и извергать желчь в сторону виндовс и прочих маков.Загвоздка в том, что недолболюбам на маках и виндовс тоже прогресс не грозит, только если прогресс в принятии ректальных зондов в виде ИИ.
Ну и при всем ужасе красноглазого ПО аналогов ему не предвидится.
> Загвоздка в том, что недолболюбам на маках и виндовс тоже прогресс не
> грозит, только если прогресс в принятии ректальных зондов в виде ИИ.Вас услышали! В новом нотпаде уже встроено. Он теперь поди по сети отсылает каждое нажатие клавиши с 100% легитимной отмазкой :). Вы же не могли жить без AI в нотпаде, правда?! :)
> Ну и при всем ужасе красноглазого ПО аналогов ему не предвидится.Вон вам чудный новый нотпад от майкрософта. Зато глаза правильного цвета, и стыд их видимо не ест :)
Посмотри вот это видео https://www.youtube.com/watch?v=YyRVOGxRKLg Торвальдс говорит за внедрения раста как раз из-за этого. Но лично он ему не нравится.
Че ты несешь? Совет директоров даже если и принимает решения, то не о каждом элементе и в каждой крупной конторе есть жесткая иерархия. Это типо император мать их японии, а это простолюдин. Простолюдин императору нихрена указывать не может потому что лидер может быть только один.
Вам дают кость из раста которую разумно можно использовать ради фич типа написания драйверов без ошибок в памяти.
То что есть извращенцы которым так проще -хрен с ними.
Но каждый червь со своими советами лезущий это не принятие важных решений.
То что ты неспособен осилить хоть что-то не значит что кто-то есть твой не так чтобы зашифрованный мат. Черви ничего Линусу не докажут.
Линус понимает как нужно вести такой проект, а ты нет. Сейчас практически весь серверный рынок линуксовый, все другие ~юниксы давно на обочине.
Потому что корпорации в эпоху Интернета быстро поняли, куда дует ветер, и решили скинуться человекочасами на разработку того, что само по себе уже не могло давать конкурентных преимуществ. Это и есть главная причина того, что Линукс взлетел. И уж точно не технологическое превосходство - до первой половины нулевых в бзде лучше было сделано почти всё, а про то, насколько лучше в это же время был солярис, даже и говорить особо не надо.
Один процент на десктопах, а не на серверах. И проблема не в ядре
Типичный пример извергания желчи от не линуксоида, обвиняющего в этом других. Ничего нового.
Форкни ядро и веди его в какое хочешь будущее.
Останавитесь!
> Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра и не позволяет постепенно переписывать код (в случае языка С++ можно по частям переводить код с языка C, так как С-код можно компилировать как C++). В поддержку использования С++ в ядре также выступили Иржи Слаби (Jiri Slaby) из компании SUSE и Дэвид Хауэллс (David Howells) из Red Hat.Round 2... Fight!
Как бы в отчасти правда, но и ложь тоже. Пустив С++ в ядро им надо будет рядом гайдлайнов накатать какие фичи использовать, а какие нет. Хотя вон гугл в хромиуме вроде смог. Но оно вам надо?
Гайдлайны, внезапно, в ядре и для Си есть. Уровень обсуждений далёких от разработки людей.
Для с++ они увеличатся на порядок из-за возможных фич языка
Пусть определятся, какие фичи в ядре допустимы. По тем и пишут.
Если на десятичный порядок, то конечно же нет, добавятся пару новых страничек
> Если на десятичный порядок, то конечно же нет, добавятся пару новых страничекВот дока по стилю С в ядре https://www.kernel.org/doc/html/v4.10/process/coding-style.html - в печати 21 страница А4
Вот для примера С++ https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines - в печати 679 страниц!
С++ гугла https://google.github.io/styleguide/cppguide.html - 89 страниц.
Chromium
https://chromium.googlesource.com/chromium/src/+/refs/heads/...
https://chromium.googlesource.com/chromium/src/+/refs/heads/...
https://chromium.googlesource.com/chromium/src/+/refs/heads/... - вот тут 50 страницQt
https://wiki.qt.io/Coding_Conventions
https://wiki.qt.io/Qt_Coding_Style
https://doc.qt.io/qt-6/best-practices.htmlЛень все расписывать, но видно невооруженным взглядом, что там явно не "пару новых страничек"
> Вот дока по стилю С в ядре"Табы это 8 пробелов..."
> Вот для примера С++
"Нас не волнует низкоуровневые вещи вроде отступов, а ещё мы предлагаем вам библиотеку."
> Qt
*Что-то не тянущее на 21 страницу*
>> Вот дока по стилю С в ядре
> "Табы это 8 пробелов..."
>> Вот для примера С++
> "Нас не волнует низкоуровневые вещи вроде отступов, а ещё мы предлагаем вам
> библиотеку."Мой оригинальный комментарий https://www.opennet.dev/openforum/vsluhforumID3/132575.html#128 содержит слово guideline. Если https://www.kernel.org/doc/html/v4.10/process/coding-style.html мешает понятия code style и guideline, то я не виноват. Для примера гугл также делает. Смотри тогда с ним.
Но я говорил именно про гайдлайн и для плюсов там сильно больше надо будет писать. Хотя бы имея ввиду сколько всего добавляется в новых стандартах. Для примера можешь посмотреть доку хромиумуа по ссылке выше.
Мозг вообще пробовал хоть немного подключать, когда писал всю эту чушь?Дока в ядре касается практически только оформления кода (CS), когда как документ от Страуструпа на кучу страниц небольшой учебник по c++ для двигающихся горизонтально. И если даже его нормально распечатаешь, а не как ты через бразуер с гигантским шрифтом, то не будет 700 страниц. 21 страница ядерного CS читается за пару минут потому что там на самом деле не 21 страница, по такой же причине.
В гугловом CS много филовского п-жа с рационализайией, его не обязательно читать чтобы понять что от тебя нужно. CS в хроиуме и Qt как раз несколько страничные и, как в случае с ядерным CS, читаются за пару минут. Могу ещё подкинуть данные, например, по Яндексовому CS - тоже 2-3 страницы на 2-3 минуты чтения. Итого, какие выводы...
1. Типичные плюсовые CS на несколько страниц и на максимум 5 минут чтения
2. Объём CS выбирает проект и если тебе удалось найти неадекватов вроде гугла, то из этого не следует, что все CS по плюсам будут такими. Пытаешься натягивать единичный пример на все, когда даже твоя подборка показывает обратное.
^ Так и не понял куда приклеился ответ, он был анониму с ссылками
>[оверквотинг удален]
> горизонтально. И если даже его нормально распечатаешь, а не как ты
> через бразуер с гигантским шрифтом, то не будет 700 страниц. 21
> страница ядерного CS читается за пару минут потому что там на
> самом деле не 21 страница, по такой же причине.
> В гугловом CS много филовского п-жа с рационализайией, его не обязательно читать
> чтобы понять что от тебя нужно. CS в хроиуме и Qt
> как раз несколько страничные и, как в случае с ядерным CS,
> читаются за пару минут. Могу ещё подкинуть данные, например, по Яндексовому
> CS - тоже 2-3 страницы на 2-3 минуты чтения. Итого, какие
> выводы...Ну ты к Яндексовому стилю не забудь прикрепить гайдлайн по использованию кода из аркадии взамену стд, если он, конечно, есть.
> 1. Типичные плюсовые CS на несколько страниц и на максимум 5 минут
> чтенияПомимо CS есть guideline. Я писал именно про guideline, а не про правила расстановки пробелов и скобок.
> 2. Объём CS выбирает проект и если тебе удалось найти неадекватов вроде
> гугла, то из этого не следует, что все CS по плюсам
> будут такими. Пытаешься натягивать единичный пример на все, когда даже твоя
> подборка показывает обратное.У гугла как раз норм описано. Просто другие это не описывают, а потом вынужден на кодревью править "вот это мы не используем", "так мы не делаем". Конкретно, в хромиуме, одну и ту же вещь можно сделать по разному, используя как std так и тамошний base. Можно, конечно, жить с херовой вики (как в Я) и пинать всех на ревью, а можно нормально описать.
> Ну ты к Яндексовому стилю не забудь прикрепить гайдлайн по использованию кода из аркадии взамену стд, если он, конечно, есть.Нет гайдлайна, раньше туда тупых не брали. Сейчас пытаешься приклеить документацию по внутреннему устройству проектов к CS по плюсам. Всё же давай начнёшь включать мозг, а?
> Помимо CS есть guideline. Я писал именно про guideline, а не про правила расстановки пробелов и скобок.
У Страуструпа на кучу страниц развёрнутый guideline, а всё остальное это в основном CS. Ну да, к Qt ещё приклеил документацию до внутреннему дизайну либ, вроде как у них устроены координатные сетки - вот это прямо таки самые настоящие СS и guideline-ы по С++ для Qt. Начни всё же включать мозг, если, конечно, он есть.
> У гугла как раз норм описано. Просто другие это не описывают, а потом вынужден на кодревью править "вот это мы не используем", "так мы не делаем"...
Чтобы рассказать как "мы (не) делаем" нужно просто рассказать "мы (не) делаем", а не тратить 80% от CS на трёп с размышлениями каким образом гугл докатился до такого CS-а. Ты же на ревью хочешь чтобы клиент просто затнулся и сделал как принято, а не рассуждал на тему верно это или нет? Потому у гугла CS построен неверно, его только спасает выделение рассуждений в визуально отдельный блок и опытный читатель может его пропускать. Тем более рационализация гугла во многих местах смехотворна, лучше бы просто написали ~ заткись и делай как тут показано.
> Можно, конечно, жить с херовой вики (как в Я) и пинать всех на ревью, а можно нормально описать.
Рассказываешь сказки с несуществующими проблемами. Таких проблем нет даже в проектах, где исторически в разных местах появились разные CSы. Типичному разработчику всё же хватает интеллекта посмотреть как было до и сделать аналогично.
>> Ну ты к Яндексовому стилю не забудь прикрепить гайдлайн по использованию кода из аркадии взамену стд, если он, конечно, есть.
> Нет гайдлайна, раньше туда тупых не брали.Просто в конторе не любят писать доку - признай это. Поэтому кичиться cs на 1 страницу не нужно. На самом много где не любят. Спорить на тему ее нужности и самодокументированного кода я не собираюсь:)
> Сейчас пытаешься приклеить документацию по
> внутреннему устройству проектов к CS по плюсам.Совсем нет. Я вроде ясно выразился, что для C++ гайдлайны (не кодстайл) придется наисать гораздо больше чем для С. Вот это и нужно обсуждать. В качестве примеров я привел существующие документы проектов.
>> Помимо CS есть guideline. Я писал именно про guideline, а не про правила расстановки пробелов и скобок.
> У Страуструпа на кучу страниц развёрнутый guideline, а всё остальное это в
> основном CS. Ну да, к Qt ещё приклеил документацию до внутреннему
> дизайну либ, вроде как у них устроены координатные сетки - вот
> это прямо таки самые настоящие СS и guideline-ы по С++ для
> Qt. Начни всё же включать мозг, если, конечно, он есть.Ты начинаешь порядком надоедать своей глупостью. По поводу qt есть страница про исключения https://doc.qt.io/qt-6/exceptionsafety.html Но ведь ты даже не удосужился прочитать. Если тебе это не нравится, то сравнивай с гугловским документом.
>> У гугла как раз норм описано. Просто другие это не описывают, а потом вынужден на кодревью править "вот это мы не используем", "так мы не делаем"...
> Чтобы рассказать как "мы (не) делаем" нужно просто рассказать "мы (не) делаем",
> а не тратить 80% от CS на трёп с размышлениями каким
> образом гугл докатился до такого CS-а. Ты же на ревью хочешь
> чтобы клиент просто затнулся и сделал как принято, а не рассуждал
> на тему верно это или нет? Потому у гугла CS построен
> неверно, его только спасает выделение рассуждений в визуально отдельный блок и
> опытный читатель может его пропускать. Тем более рационализация гугла во многих
> местах смехотворна, лучше бы просто написали ~ заткись и делай как
> тут показано.Ну может у тебя есть ссылка на твой замечательный документ, который описывает как надо делать. Покажи его нам.
>> Можно, конечно, жить с херовой вики (как в Я) и пинать всех на ревью, а можно нормально описать.
> Рассказываешь сказки с несуществующими проблемами. Таких проблем нет даже в проектах, где
> исторически в разных местах появились разные CSы. Типичному разработчику всё же
> хватает интеллекта посмотреть как было до и сделать аналогично.Выше уже ответил по теме доке. Вижу, что проблема осталась.
>> Ну ты к Яндексовому стилю не забудь прикрепить гайдлайн по использованию кода из аркадии взамену стд, если он, конечно, есть.
> Нет гайдлайна, раньше туда тупых не брали.А в гугл берут тупых по твоей логике раз у них есть гайдлайн? Чтож тогда яндексоиды пулей летят в гугл к тупым как только получают офер?
> А в гугл берут тупых по твоей логике раз у них есть
> гайдлайн? Чтож тогда яндексоиды пулей летят в гугл к тупым как
> только получают офер?Судя по ряду проектов гугли - и их участи - типа, вот, фуксии - похоже что берут.
> Дока в ядре касается практически только оформления кода (CS), когда как документ от Страуструпа на кучу страниц небольшой учебник по c++ для двигающихся горизонтально.Оригинально я писал про гайдлайн, а не cs. Если ядро смешивает их, то ко мне какие вопросы. Вон гугл тоже смешивает, сравнивай с ним.
> И если даже его нормально распечатаешь, а не как ты через бразуер с гигантским шрифтом, то не будет 700 страниц. 21 страница ядерного CS читается за пару минут потому что там на самом деле не 21 страница, по такой же причине.
Ну выстави нужный шрифт и пришли результат. Мне влом этим заниматься. Но там явно не "на пару страничек больше". Можно хотя бы просто сравгить, что добавляет каждый новый стандарт С++ и С, и сделать из этого вывод о размере гайдлайна.
Выше рассуждаешь про вполне конкретную штуку - линуксовое ядро и c++ в нём. А значит и рассматривать должен ровно то, что там есть. Логично же, не так ли?> Можно хотя бы просто сравгить, что добавляет каждый новый стандарт С++ и С, и сделать из этого вывод о размере гайдлайна.
Можно, но придётся опять включать мозг: большая часть изменений касается STL, которого в ядре не будет если туда завезут плюсы.
AUTOBOT - это блочит (и я не знаю почему):
А как они собираются исключения туда затянуть? (этого сделать вероятно не получится, да и не нужно)
А без исключений затянут - это будет не C++, а просто "подмножество" C++ - типа "чуть улучшенный C".
Ах да - это они всё ради темплэйтов наверное!P.S. А в Расте есть исключения?
Разумеется, ведь самая главная фича плюсов это исключение
Пока нашёл там обработку ошибок. То есть функция может вернуть либо результать, либо ошибку. И ошибка при этом вполне себе конретный тип данных, с которым можно дальше работать, например, завершив программу с сообщением или продолжить дальше работать, решив проблему.
> Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядраЭто такой лол, что я даже не знаю, что сказать. Но когда пропадёт калабуховский дом, с рожей вонки буду сидеть.
Здравый смысл, наконец-то берет верх..
Да уж, беда пришла откуда не ждали... Если что-то и может быть хуже С, то это С++.
Поправил, не благодари> Да уж, помощь пришла откуда не ждали... Если что-то и может быть лучше С, то это С++.
Единственная проблема плюсов в ядре -- это привычки и отношение к языку значительной части сишников. И вопрос тут не в том, кто прав, а кто нет. Люди годами писали ядро, потому их точка зрения имеет вес. Однако, после внедрения Rust этот аргумент превратился в тыкву.
То, что будет возможность писать на плюсах совсем не означает, что толпы молодёжи (уже смешно) побегут яростно переписывать все ядро. Так что как пилили деды свою сишную часть, так и будут, пока (если) не будет вытеснена чем-то более актуальным.
Толпам молодёжи (и немоложёжи) вообще срать на ядро, они от него в принципе с удовольствием подальше держаться будут. Но не всегда есть такая опция. Драйвер сам не напишется... Нужен нормальный плюсовый фреймворк для драйверов.
Под фреймворком обычно понимается что-то тяжёлое. На плюсах возможно реализовать библиотеку без лишних накладных расходов.
На деле, плюсы в ядре повышают порог вхождения по сравнению с Си.
Лол, молодёжь на javascript пишет, ей что сишечка что плюсы это древние рукописи
> Изначально тема разработки ядра на C++ была поднята в 2018 году инженером из Red HatЭто что, реклама Red Hat между делом? Данному разговору уже не первое десятилетие.
> С инициативой продолжения обсуждения выступил Ганс Питер Анвин (Hans Peter Anvin)
Сомневаюсь, что люди со стороны могут по предоставленному послужному списку оценить реальную авторитетность мнения данного разработчика. Напишите лучше новость, если Линус или Грег удостоят его мнение ответом.
> Возможности, для которых ещё недавно приходилось привлекать специфичные GCC-расширения, теперь легко реализовать на стандартном C++
А актуален ли вопрос вообще? Недавно читал, что ядро нынче нормально собирается Clang-ом.
>>ядро нынче нормально собирается Clang-ом.Это как раз именно потому, что в нём нет С++
Я так подозреваю, что ядро на голой сишке писали, чтобы не было никакого неявного кода. По сути всем понятно, что любой ООП можно реализовать и без поддержки ООП в языке. На структурах и прописывая весь скрытый в ООП код ручками. Так возможно получится быстрее. Немного. Ну самый простой пример это managed строковые типы. Они безопаснее. Но они требуют динамического выделения памяти буквально на каждом шагу. А это на самом деле лишние тормоза. Чтобы не было никакого неявного тормозного кода - лучше юзать char*. Вы же знаете, что сегодняшних программистов учат в школе прогать на Питоне как обезьянок? Если им позволить юзать в ядре плюсы и stdlib - они ведь будут юзать самые тормозные конструкции, какие только можно. Они и PHP его бы на писали, если бы можно было.
>По сути всем понятно, что любой ООП можно реализовать и без поддержки ООП в языке.Можно, но костыльно очень. Или хотите в ядро нечто, наподобие Glib?
>На структурах и прописывая весь скрытый в ООП код ручками.
Это человеконечитаемо, лапшакод. И зачем для каждого "класса" проделывать ручками одни и те же действия?
Ядро писали на Си, потому что плюсов тогда толком и не было.
Ну были, конечно, уровня Borland C++. А вот был ли свободный g++ в 1991, не знаю.
Был где-то с 87-го: https://gcc.gnu.org/releases.html
Гипотетически они может и были, а практически стандарт языка принят в 98-м.
> Я так подозреваю, что ядро на голой сишке писали, чтобы не было никакого неявного кода.Никакого -- утверждение слишком сильное для сишки. Как минимум из-за неявного преобразования типов.
Впрочем, по сравнению с крестами, я склонен согласиться: с крестами неявного кода было бы на порядки больше.> По сути всем понятно, что любой ООП можно реализовать и без поддержки ООП в языке. На структурах и прописывая весь скрытый в ООП код ручками.
Я кстати пробовал так писать на сях. В силу их синтаксиса, к сожалению, получается весьма многословно, и работать с этим не так удобно, как хотелось бы. Впрочем, я склонен считать, что это проблема не собственно Си, а самой концепции ООП в целом.
А так, как описываете Вы, ООП успешно добавляется в более высокоуровневые языки: Lisp-ы, ML-и, тот же Perl вон... То есть поинт тут в том, что так делать удобно только в случае использования языков более высокого уровня: причём крайне желательно, чтобы они обладали встроенными инструментами изменения своего синтаксиса.
> Так возможно получится быстрее. Немного. Ну самый простой пример это managed строковые типы. Они безопаснее. Но они требуют динамического выделения памяти буквально на каждом шагу. А это на самом деле лишние тормоза.
О том и речь: высокоуровневым языкам -- высокоуровневые задачи, и наоборот.
> Вы же знаете, что сегодняшних программистов учат в школе прогать на Питоне как обезьянок? Если им позволить юзать в ядре плюсы и stdlib - они ведь будут юзать самые тормозные конструкции, какие только можно.
Вот-вот. Тут та же логика, как когда тебя приглашает зайти на чай красивая девушка, но ты не идёшь, потому что она работает в стриптиз-клубе. В том смысле, что выбор инструмента -- это в частности вопрос социальный: архитектор смотрит не только на сам инструмент, но и на сообщество, которое вокруг инструмента сформировалось. И если сообщество ему не нравится -- то и инструмент выбран не будет.
По части самого вопроса, тут на самом деле ни черта не ясно, зачем это нужно. Как бы, крестовики спокойно могут и на голом си написать модуль, если им потребуется, ибо всё-таки в некотором смысле одно является субсетом другого. Так и зачем тогда напрягаться, поддерживать какой-то дополнительный интерфейс? Статус-кво вполне удовлетворяет нуждам проекта.
Rust тоже не ООП язык. Вполне себе можно писать крупные проекты и в процедурном стиле, и в ООП, и в функциональном стиле. ООП переоценён, это не золотой молоток. А уж взглянув на Java Enterprise FizzBuzz страшно смотреть.
В ООП стиле на расте писать нельзя т.к. нет наследования. ООП в самом деле не киллер фича, но на задачах, где оно нужно, без поддержки ООП тяжко
> В ООП стиле на расте писать нельзя т.к. нет наследования. ООП в
> самом деле не киллер фича, но на задачах, где оно нужно,
> без поддержки ООП тяжкоВ каких задачах нужно ООП?
Тот же бизнес с иерархией документов, где каждый с небольшими отличиями, ролями. Медицина, эконометрика, области математики со сложным поведением объектов. Тысячи их.
> Тот же бизнес с иерархией документов, где каждый с небольшими отличиями, ролями.
> Медицина, эконометрика, области математики со сложным поведением объектов. Тысячи их.На самом деле ООП там нужен только потому, что ООП является отдельной индустрией-в-себе: это своя особая экосистема, свой собственный мир, у него свои разработчики, свои проблемы и своя головная боль. По существу, он нужен только там, где разработка уже в этой экосистеме живёт. Поскольку в высокоуровневых языках объекты первого порядка давно являются само собой разумеющимися вещами, то кроме выше названной социальной -- потребности в ООП-е как таковой нет: код на фанкторах пишется и понимается куда проще.
> код на фанкторах пишется и понимается куда проще.Если объекты (в плане понятий из предметной области) однотипные. Любая, даже минимальная, иерархия приводит к росту гемороя в геометрической прогрессии. Люди думают понятиями а не раздельно существующими матрицами свойств.
> Люди думают понятиями а не раздельно существующими матрицами свойств.Что ближе к корове, трава или курица?
Аналитик ответит, что курица, потому что они оба -- животные.
Холист ответит, что трава, потому что корова её ест.Надо уметь думать и так, и эдак. Тезис о том, что "люди думают понятиями" -- это ошибка и одновременно оправдание, чтобы не осваивать мышление иного рода.
c++ это не либа работы со строками. Причины совершенно в ином - нет API и нет гарантий на оптимизации сахара. Тем более если ещё брать c++ образца начала 2000, то вообще ужасный ЯП с минимум оптимизаций сахара компилятором.
Это у Red Hat всё шуточки первоапрельские, а между тем Эпол, например, вполне успешно и уже давно применяет Embedded С++ для написания системных Kernel extensions (драйверов) в ядре XNU для всей линейки своих OS (macOS, iOS, iPadOS & e.t.c.) ...
У эппла анально-ректальные стайлгайды и референсы. Во-вторых, эпплы сами выпускают железо и сами пишут под него. В отличии от линпус-зоопарка, у них чёткий список устройств, которые должны работать с теми или иными компонентами.
Винда написана на С++ и работает на огромном зоопарке устройств.
Не такой уж и зоопарк, всего полтора типа железа, которое в ней поддерживалось изначально. Зато её в бсод отправляет и открытие ютуба в браузере и сохранение файла в блокноте, про регулярно разлетающиеся файловые таблицы можно не вспоминать. Показательный уровень.
Отличие кстати в том, что железо разрабатывают под ОС, потом костыляют адовые блобы с кучей костылей чтобы хоть как-то работало. В линуксе на помойные драйвера смотрят криво.
Какие полтора типа? Минимум шесть.
> её в бсод отправляет и открытие ютуба в браузере и сохранение файла в блокноте, про регулярно разлетающиеся файловые таблицы можно не вспоминатьWindows не виновата в том, что у тебя лапки.
>Минимум шесть.Суть в том, что они там были испокон времён, ничего нового, и то на хлам с армом пришлось влить миллиарды миллиардов 15 лет назад, который всё равно оказался нежизнеспособным.
>Windows не виновата в том, что у тебя лапки.
Ну, тут виноваты windows update и неквалифицированные некомпетентные кадры в microsoft, не сама windows, понятное дело.
> Зато её в бсод отправляет и открытие ютуба в браузере и сохранение файла в блокноте, про регулярно разлетающиеся файловые таблицы можно не вспоминать. Показательный уровень.Выкинь уже свой зион с али, с «ECC»-памятью.
Твои фантазии унылые, фиксация какая-то?
Во-первых, стайлгайды и референсы не имеют никакого отношения к технологиям программирования. Это чистая политика компании.
Во-вторых, пример успешного написания кучи драйверов энтузиастами-хакинтошниками для железа, которого никогда отродясь не было в железе Эппле чётко доказывает, что и второй ваш довод является примером газификации луж...
> хакинтошникамиИ ты ещё что-то там про газификацию луж пишешь? Лол.
Вообще вопрос надо ставить глобально. Зачем ограничения на язык для разработки модулей ядра? Далеко не всякие модули включаются в состав поставки ядра. Если так хочется, то пусть ядро и комплектные модули будут на С, но сторонние разработчики должны иметь возможность писать на любых языках. Я 20 лет страдал как единственный разработчик на фирме. Либы для разных платформ на С++ с общим кодом практически, а с драйверами вечная боль С++ под вин и С под линукс. причем лет 15 назад были патчи на ядро которые финские студенты написали емнип которые давали возможность собирать ядро с++ компилятором...
Та же мысль. В Сишный интерфейс функций умеют почти все языки, пусть ядро остается на Си, а модули пишут кто на чем хочет.
собственно, а кто запрещает?
Тогда как собирать всю эту мозаику? У инструментов будут свои зависимости, а у тех еще зависимости... А так-то я сам не против.
Зачем? ибо когда придёт какой-нибудь С++50, который наконец-таки превратится в Rust, - все с недоумением будут чесать репу!ПС: Современный С++, можно охарактеризовать примерно тем, что написано в каждой книге по этому самому современному С++, например:
You can use whichever C++ compiler you like. At the time of this writing, no compilers were fully C++XX-compliant yet. Some new features were only supported by some compilers and not others, while other features were not yet supported by any compiler. Compiler vendors are hard at work to catch up with all new features, and I’m sure it won’t take long before there will be full.
Это я к тому, нафиг он нужeн, когда уже есть готовый Rust!
Наверное, разработчикам ядра Linux все же виднее, зачем им нужен C++ и почему Раст для них не подходит.
"Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра"
> какой-нибудь С++50, который наконец-таки превратится в RustТы думаешь, что в C++50 порежут все что можно по самые помидоры?
Так что останется одна заготовка языка?
давно пора
Руст действительно будет интереснее, а кресты уже показали несостоятельность за годы существования. Когда-то думал, что взлетит D-шка, но увы.
Интереснее побаловатся на раз, а так С++ зрелый язык промышленной разработки и продожает активно использоватся, особенно в коммерческой разработке.
А чем D не взлетел?! Что в этом языке такого плохого, что его нельзя использовать для ведра?
Ну вообще плюсы в ядре - здраво, но с оговорками.
Исключения придётся вымести, по понятным причинам.
STL тоже придётся вымести, в основном из-за отсутствия единого аллокатора.
С другой стороны, отсутствие STL кстати как раз отпугнёт целую массу тех, кто в не-плюсовый C не осилил.
Какие ещё целые массы тех, кто в не-плюсовый C не осилил - как они вообще окозались в разработчиках ядра-Линукс ???
Человек не понимает, что ядро пишется корпорациями на деньги корпораций. Им и решать, какой язычок использовать, а какой - нет.
Цель как раз в том, чтобы они в них и не оказались :)
Сходи к попам, посмотри на их кресты. Пойми, чем плюс отличается от креста.
Но какую-то лёгонькую реализацию STL для целей внутри ядра, всё же, не помешает. Например, Vector и Array - большая польза. Хотя бы, чтобы за пределы буфера не выходить.
> STL тоже придётся вымести, в основном из-за отсутствия единого аллокатора.Во всех контейнерах STL можно передавать собственные аллокаторы. Можно хоть для каждого аллокатора сделать свой набор классов, и это будет намного чище и безопасней дёрганий кошмарных malloc'ов и бесконечной ручной проверкой высвобождения всех сырых указателей.
STL это вообще по большей части набор шаблонизированного кода, странно это не знать.
Соглашусь только за C++20. Хотя да, в принципе о нём и речь.
Вместо STL будет своя либа с примитивами в c++ стиле. STL для ядерных целей не подходит
> Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра и не позволяет постепенно переписывать кодЯ, конечно, не участвую в разработке ядра и не мне решать (как и многим комментаторам тут), но синтаксис С++ будет в разы хуже, чем Rust. Но, к сожалению, ядро пилит кучка ретроградов-неосиляторов.
Как раз неосиляторы и впариают новые языки. Писать на них они тоже не умеют, но в резюме такие детали можно упустить.
Впарили раст в ядро - корпорации, их ядро, а не неосиляторы. У корпораций нет интересов писать на сишке, потому что им, по их причинам нужен раст. А обычные любители будь-то сишки или раста ничего не решают.
Что-то по вакансиям не сильно этого заметно.
Какие такие вакансии? Ты о чём? Речь про ведро, корпорациям-хозяйкам ведра не нужны никакие вакансии, разрабы уже есть у них.
> синтаксис С++ будет в разы хуже
> к сожалению, ядро пилит кучка ретроградов-неосиляторовИ кто же это тут несолилятор, лол.
Ядро windows написано на С++.Вопрос об использовании С++ давно закрыт. Это работает.
Но даже windows переходит на Rust.
В винде архитектура гибридная. Они могут позволить себе какие-то независимые части сделать на более других языках. Поэтому и С, и С++ и С#. И вот даже Rust.С линуксом и его монолитной архитектурою...
Пиши драйвера в пр-ве пользователя на чём угодно
Не переходят, а пишут отдельные модули. Там же не идиоты переписывать работающий код в которй инвестированы миллионы.
> windows
> работаетНу, работать та работает. Но вот как работает...
Нормально работает. Десятки миллионов серверов и сотни миллионов десктопов по всему миру.Не говоря уже про например медицинскую технику, управлялки станками и прочие кошерные вещи.
по-дефолту в плюсах нет инструментов для безопасной работы с памятью. RAII и smart поойнтерс - это совсем недавно любители плюсов нашкрябали, плюсы - сплошной ансейф. УРА товарщи!
> RAII ... was developed for exception-safe resource management in C++ during 1984–89Очнись, наркоша. Смарт поинтеры в плюсовых проектах уже более 30 лет в том или ином виде, до стандартного STLя доехали лет 13 назад.
Ну ты и оболтус. Ну так по дефолту усё это выключено, в опенсорсе твоё стл никто не пользует. Твои плюсеги - сплошной ансейф, а когда находятся cve в плюсовых опенсорсах - разрабы отвечают: ну я забыл заюзать эту фичу. Ахахаха, плюсовеки, такие плюсоеки.
Если так хорошо работает, почему везде линукс? Фактически сиплюсы используются только для игр. Винды - ось для запуска игр.
Я прихожу к врачам, в мрт винда, на рентгене винда, в аппарате узи винда.Смартфон соединить с ноутом? Производители делают только для винды. Нормальный офис? Винда. Нориальный почтовый клиент с календарями, встречами и прочими плюшками? Опять винда.
Управление зоопарком десктопов? Винда. Удалённый доступ с аппаратными ключами? Винда.99% промышленных софтов, на которых работать можно, опять винда.
Не хочется тебя расстраивать, но это не от того, что винда хорошо работает. Это бизнес, ничего личного.
Причем тут бизнес если даже бизнес-линукс, типа шапки мимикрирует под винду?
2 самых распространенных DE копируют решения из МАС оси и винды.Или ты хочешь, чтобы бедный врач пердолился с гентой или другими маргинальными дистрами?
Искал дрова к специфическому оборудованию типа ЭЭГ/ЭКГ?В цивилизованных странах будет еще какая-то платформа для командной работы.
Назови какое-то нормальное опенсорс решение (без шуток было бы интересно)
Путаешь интерфейс и подложку.
На подложке в этих же аппаратах - далеко не винда.
Возможно, но например банкоматы я встречал на винде.
Винда IoT Core вполне достаточно большому кол-ву медицинской техники.
Я уже молчу про Windows CE)Хотя объективно для серьезного аппарата (типа радиотерапия или КТ) я бы постремался использовать ядро линукс.
Уж лучше пусть будет какой-нибудь РТОС.
Банкомат - слишком примитивное устройство. Дисплей, кейпад, принтер и полтора ком-порта для кард-ридера и денег.
В самом аппарате, который деньги выдаёт, контроллеры бывают разные, но они автономные. Где-то возможно и линуха даже.
> Банкомат - слишком примитивное устройство. Дисплей, кейпад, принтер и полтора ком-порта
> для кард-ридера и денег.У одной фирмы я видал там характерную лужайку с кнопкой Start. Или, не менее пафосный скринсейвер с логотипом XP.
А у другой после проскока питалова - вся загрузка как на ладони, но там еще после старта антивирь пашет. И пока он пашет - тадам - можно шарахаться по морде банкомата жамкая сенсорный экран, проводник точно запускается. Потом конечно морда запускается и все вышибает, но пошариться проводником по банкомату... ээ... ну им так кто-нибудь и бабки снимет при случае наверное. В мои планы такой тупой кибекриминал не входил, чисто проверка "так можно было?!", но оказалось что таки - можно! :)))
Не хочется тебя расстраивать, но бизнесу нужно чтобы всё просто работало за минимальную стоимость, ничего личного. Будет это линукс, винда, или ещё что-то - бизнесу неважно. А построением мирового open-source коммунизма пусть занимается кто-то другой.
Всё очень просто.
На интерфейсе для врача - винда. В МРТ, на рентгене, в аппарате УЗИ.
А вот внутри аппарата - либо линуха, либо RTOS'ы.
Внутри аппаратов чистое железо с прошивкаме. Накой там ОС?
Прошивки прямо в металле? :D
Вы недооцениваете современные прошивки.
То есть винда тебе только картинку рисует, всеми же серьёзными задачами занимаются совершенно другие ОС.
Совершенно другие ОС даже не в состоянии нарисовать картинку, ОК.
Там программеры другие, они занимаются не рисованием картинок, а работой со сложным железом.
ви таки недооцениваете сложность рисования картинок по данным, полученным от сожного железа.
Картинки рисовать - тоже сложно, не спорю, но это больше математика.
Ну и плюс весь видеовывод и т.п. как раз винде и отдаётся.
Короче есть разница: тупо на CPU процессить данные или работать с кучей датчиков и актуаторов.
>Я прихожу к врачам, в мрт винда, на рентгене винда, в аппарате узи винда.Потому, что в Скрепной медоборудование закуплено 15-летней назад разработки? А то и ваще б/у.
Закупаем такие современное оборудование (с условием, что нам его кто-то продаст)… а там опять винда. Да что ж такое.
Ядро винды написано на Си
>Ядро windows написано на С++.Откуда вы эту муйню все копируете? Ядро винды написано и продолжает писаться на C. Так же там есть asm и якобы его там достаточно много. Никакого С++ и чего-то ещё там нет и скорее всего не будет. Винду далеко не идиоты пишут.
Достаточно интервью в котором мелкомагкие переписывальщики на раст говорят о том, что занимаются переводом внутренних C++ типов в эквивалентные раст.
> и язык C++ стал лучшеВроде же не 1 апреля еще? Автор цитаты выше Перепил на новый год и думает что наступило 1 апреля?
Основное возражение для С++ в ядре было, что он слишком много прячет от разработчика, а для ядра это неприемлимо. И с тех пор C++ стал хуже, появилось еще 100500 способов выстрелить себе в ногу.
Как, как язык поддерживающий обратную совместимость может стать лучше? Или пометили как устаревшие std::auto_ptr и std::vector<bool> и все, все проблемы решены?
> И с тех пор C++ стал хуже, появилось еще 100500 способов выстрелить себе в ногу.Все способы выстрелить себе в ногу в C++ - это исключительно наследие C. На чистом плюсовом коде (без сырых указателей, сишных строк и функций) выстрелить себе в ногу очень сложно. Правда сишники начинают беситься от ошибок компилятора, и начинают в обход компилятора фигачить свой сишный код, это да.
> начинают беситься от ошибок компилятораА кто не начнёт, когда в шаблонном коде получаешь ошибку в коде кишок?
> Все способы выстрелить себе в ногу в C++ - это исключительно наследие
> C. На чистом плюсовом коде (без сырых указателей, сишных строк и
> функций) выстрелить себе в ногу очень сложно.А дебильные классические типы целых чисел там как? Их так то и в си неплохо бы выпилить к хренам и сделать по уму, на основе C99 - и с "well defined behavior". Это спасло бы от дохреналиона багов и вулнов на ровном месте.
И да - вообще забанить к хренам "int" (signed) как индексы. С расстрелом из реактивного г@вномета за это. Чтобы господам даже чисто теоритически в голову не приходило что в массив можно отрицательный индекс, бдаж!
Ты не поверишь, но отрицательный индекс в массиве по указателю - очень даже востребован.
В производстве овно кода и CVEшек?
Верю! Можно просто открывать новости пенька и каждый 2 недели читать про очередную уязвимость от любителей поиграться с индексами.
Но вот для надежных систем это только во вред.
Вот есть у меня вот прямо индекс указателей на элементы. Есть поинтер на какой-то указатель в этом индексе.
Мне надо предыдущий взять. Далее чего?
Так твой пример сам по себе небезопрасный. И на этот случай есть унарный --, знак тут всё ещё не нужен
Мне не нужно менять сам указатель :)
> Вот есть у меня вот прямо индекс указателей на элементы. Есть поинтер
> на какой-то указатель в этом индексе.
> Мне надо предыдущий взять. Далее чего?Уволить того кто код так пишет к хренам - зачем вам этот генератор CVE в тиме?
Да не, я не против, чтобы ты вместо одного сервера у меня 10 купил, но ты ведь не купишь.
> Да не, я не против, чтобы ты вместо одного сервера у меня
> 10 купил, но ты ведь не купишь.Я как махровый сишник готов поспорить что все то же самое можно было сделать значительно менее ректально. Без явно невалидных на глаз (и статический анализатор) действий.
То что вы делаете что-то ректально и гордитесь этим намекает что хрустики все же имеют свой понйт в своем желании вас уйти. Той е#$%нины в коде лично я не желаю видеть в принципе.
На самом деле пусть уходят - чище будет.
> На самом деле пусть уходят - чище будет.Инихрена себе уровень самокритики. Вот это вы круты. Я правильно понимаю что вы считаете что без вас в проекте станет лучше? O_O Да, это довольно необычно для опеннет...
> Ты не поверишь, но отрицательный индекс в массиве по указателю - очень
> даже востребован.А вот эксперты по фигурному прострелу пяток с заподвыподвертом пожаловали. Я все понимаю - но вот в именно таком стиле CVE получаются. Воон там зубр сабмитил отрицательный индекс массиву если вооон те параметры на вход дать. Не, так не задумано - просто он аргументы функции на вход не чекал, и получив воооон те параметры, лихо проматывал индекс не только до 0 но и за него. Ну, подумаешь, по чужой памяти пошарился, а то и в провод слил, "ишь ты, карманный вариант heartbleed'а". Гнать таких програмеров ссаными тряпками и ср@ной метлой.
> сделать по уму, на основе C99 - и с "well defined behavior".Хахахаха, ты предлагаешь невозможное.
Сейчас набигут фанатики и объяснят тебе, что UB это лучшее что есть в дыряшке, приведут кучу примеров где оно ну обязательно и без них даже кушать нельзя.
Самое глупое оправдание которое мне тут попадалось было "если напишут без уязвимостей, как мы будем рутовать телефоны"
Лучше уж Rust. C++ это нагромождение костылей, если все это (особенно метапрограммирование на шаблонах) попадет в ядро то туши свет. Rust хоть и имеет более непривычный синтаксис чем С++, но все же разработан с учетом опыта многих других языков.
Да, только раст спасёт ведро линукс!
Да дело не в том что кто-то чего-то спасет. Языки программирования объективно развиваются. Когда создавали Си, многих возможностей просто не было. Си получился очень удачным, но все-же есть у него и недостатки, и чем сложнее проект тем чаще они вылезают.
А вот тащить С++ я бы не стал. Именно потому, что он развивался эволюционно. Добавляли фичи, потом оказывалось что добавили не совсем удачно - добавляли поверх новые, а старые не совсем удачные оставляли... в результате получилось некое нагромождение всякого разного.
Постоянное беспокойство за "обратную совместимость" до добра не доводит никогда.
А все что нужно было сделать - что-то вроде pragma version в начале каждого сpp файла. И для новых версий можно было бы не бояться ломающих изменений в языке. Компиляторы бы поддерживали сразу несколько версий, в результате программисты бы спокойно переходили на новые версии и по мере возможностей подтягивали бы старый код.
> А все что нужно было сделать - что-то вроде pragma version в начале каждого сpp файла.А опция --std компилятору не подойдет? :)
Для реализации ломающих изменений и сохранения возможности компиляции старых файлов - не подойдет. Кроме того, хранение версии языка отдельно от исходника само по себе плохо.
Это само по себе хорошо т.к. не нужно править дохринилиард прагм во всём репозитории при переходах на новые стандарты. Дерьмовее предложения, чем помечать каждый исходник версией, просто невозможно придуамать.
> Это само по себе хорошо т.к. не нужно править дохринилиард прагм во
> всём репозитории при переходах на новые стандарты. Дерьмовее предложения, чем помечать
> каждый исходник версией, просто невозможно придуамать.Да нет. Наоборот. Если захочется применить в исходнике новые возможности, то ты туда _уже_ пойдёшь редактором. И поменять при этом pragma - не проблема. Исходник должен сообщать сам о себе версию стандарта. Это правильно и логично.
>> Это само по себе хорошо т.к. не нужно править дохринилиард прагм во
>> всём репозитории при переходах на новые стандарты. Дерьмовее предложения, чем помечать
>> каждый исходник версией, просто невозможно придуамать.
> Да нет. Наоборот. Если захочется применить в исходнике новые возможности, то ты
> туда _уже_ пойдёшь редактором. И поменять при этом pragma - не
> проблема. Исходник должен сообщать сам о себе версию стандарта. Это правильно
> и логично.Правильно и логично - когда не надо менять код под каждый новый стандарт.
Любая необходимость менять должна быть исключением из правил.
Вот эти исключения из правил и надо выявлять. Компилятор это делает.
Можно было бы создавать отдельную утилиту, но зачем?
> Правильно и логично - когда не надо менять код под каждый новый
> стандарт.А зачем его менять, если как предлагается выше, компиляторы поддерживают разные версии? Есть у тебя исходик с pragma version 2014 и на здоровье.
>> Правильно и логично - когда не надо менять код под каждый новый
>> стандарт.
> А зачем его менять, если как предлагается выше, компиляторы поддерживают разные версии?
> Есть у тебя исходик с pragma version 2014 и на здоровье.Например, что бы оптимизации сработали. Смотри lto.
>>> Правильно и логично - когда не надо менять код под каждый новый
>>> стандарт.
>> А зачем его менять, если как предлагается выше, компиляторы поддерживают разные версии?
>> Есть у тебя исходик с pragma version 2014 и на здоровье.
> Например, что бы оптимизации сработали. Смотри lto.Если pragma version относится только к синтаксической части, то оптимизации здесь ни при чём и их можно рулить параметрами командной строки компилятора.
>>>> Правильно и логично - когда не надо менять код под каждый новый
>>>> стандарт.
>>> А зачем его менять, если как предлагается выше, компиляторы поддерживают разные версии?
>>> Есть у тебя исходик с pragma version 2014 и на здоровье.
>> Например, что бы оптимизации сработали. Смотри lto.
> Если pragma version относится только к синтаксической части, то оптимизации здесь ни
> при чём и их можно рулить параметрами командной строки компилятора.Стандарты очень часто вводят для включения возможности оптимизации. На старых стандартах возможностей оптимизации меньше. Или в вашем любимом языке это не так?
> Стандарты очень часто вводят для включения возможности оптимизации. На старых стандартах
> возможностей оптимизации меньше. Или в вашем любимом языке это не так?Оптимизации - расплывчатое понятие. Что я вижу в новых стандартах C и C++ это не какие-то скрытые оптимизации поверх старого синтаксиса, а как раз изменения в синтаксисе, добавление чего-то нового с целью упрощения чего-то старого. И для того, что бы повившиеся анонимные структуры, инициализация по именам полей структуры и т.п. работало, надо сделать таки изменения в исходном коде. Для этого туда надо зайти. И заодно поменять pragma version. Не вижу проблем.
На изменение обработки volatile смотрел?
На расширение того, что при constexpr уйдет в компиле тайм смотрел?
> Для реализации ломающих изменений и сохранения возможности компиляции старых файлов - не
> подойдет.Странно, но именно для этого его и используют. Конечно там включается до.. гхм... очень много дефайнов, которые можно учесть в исходниках.
> Кроме того, хранение версии языка отдельно от исходника само по себе плохо.
Чем? Вносимые в язык изменения продуманы так, что если что-то работает - то будет работать. Если что-то не работает - то оно не соберётся и ты вынужден будешь внести изменения.
> Компиляторы бы поддерживали сразу несколько версий, в результате программисты бы спокойно переходили на новые версии и по мере возможностей подтягивали бы старый код.В результате программисты просто бы никуда не переходили. Совместимость со старыми стандартами и так достаточно глубокая по вермени. Проблемы обычно возникают с некорректным использованием поюсов.
rust разработан с учётом надёргивания из маргинальных ЯП фич, которые очень хотелось подёргать хипстерам из команды разработчиков. Другими словами, разработан с учётом опыта языков с низким практическим применением.
> Лучше уж Rust. C++ это нагромождение костылей, если все это (особенно метапрограммирование
> на шаблонах) попадет в ядро то туши свет. Rust хоть и
> имеет более непривычный синтаксис чем С++, но все же разработан с
> учетом опыта многих других языков.Про C++ согласен. Но и rust не нужен. Пусть пишут свои проекты. Зачем в ядро лезть. Там всё норм.
>метапрограммирование
>произвольные вычисления во время компиляции
>безопасная работа с памятьюЧего только не сделают, лишь бы переизобрести лисп в своем языке...
Отправляйте всех любителей оного в нашу палату, пусть лучше на человеческом языке Mezzano OS пилят, а не гробят Линукс своими прогрессивными франкенштейнами.
хруст до добра не доведет
https://habr.com/ru/articles/786366/
Забавное в комментах, все что нужно знать
Какой смысл C заменять на C++? Между ними нет никакой принципиальной разницы. C++ такой же морально устаревший динозавр, как и C, просто еще более уродливый и окостыленный. Вот Rust, Carbon или Zig - более лучшие и современные кандидатуры. Я лично голосую за Rust, ибо он предлагает принципиально новую парадигму программирования, как бы там не пыхтели хейтеры этого языка.
Никаких новых парадигм в расте нету.Тогда уже лисп давайте
> Никаких новых парадигм в расте нету.Тогда уже лисп давайтеПутались в указателях, теперь будут путаться в скобочках.
1. Раст требует грёбанного тулчейна.
2. Хотя-бы потому, что на крестах доступны растопримитивы и это позволит инкрементно переводить код на раст. То есть сначала потихоньку сишный код переписывается на кресстовый. Потом крестовый приводится к растоподобному стилю. Потом переписывается на раст, фиксятся баги компиляции, фиксы бэкпортируются на кресты. Каждый патч проходит ревью. Тем самым обеспечивается преемственность, последовательность и контроль на каждом этапе.
Именно, а Раст без тулчейна и с unsafe теряет свои главные преимущества и принципиально ничем не отличается от Си.
> Раст требует грёбанного тулчейна.а с или с++ не требуют грёбанного тулчейна !?
как же тогда текстовые файлы с исходным кодом преобразуються в выполняемые бинари/библиотеки?
> Какой смысл C заменять на C++? Между ними нет никакой принципиальной разницы.
> C++ такой же морально устаревший динозавр, как и C, просто еще
> более уродливый и окостыленный. Вот Rust, Carbon или Zig - более
> лучшие и современные кандидатуры. Я лично голосую за Rust, ибо он
> предлагает принципиально новую парадигму программирования, как бы там не пыхтели хейтеры
> этого языка.Сам ты морально устаревший. C такой же устаревший как ложка с вилкой. Да что это за болезнь такая тащить всё модное всюду без разбора? А оно, вообще, в ядре надо? Надо ядру принципиально новая парадигма? Что за гуманитарный бред? C работает, справляется со своей задачей хорошо. Проще ЯП при его возможностях нет на данный момент. Сложнее и хуже - навалом. Нафига это всё тащить в ядро - непонятно. От скуки и скудоумия. Работой займись.
>Да что это за болезнь такая тащить всё модное всюду без разбора?Обычная болезнь зумеров. Знаний - мало, энергии - много, страсть ко всему новому (для их мозга). Увидели - слюни потекли, побежали ставить/канпелять. Плюс, такие же клоуны как они подливают масла в огонь своими "хелловорлдными" статейками (которыми только подтереться). И вот уже кто-то всерьёз обсуждает Раст.... *фэйспалм*
Нет, к чёртовой матери таких товарищей.
Не узнаю вас, анонимы. Ловко вас провели. Что, уже идея с растом не так плоха как раньше?
Судя по реакции, скорее наоборот. Под угрозой включения Rust в ядро все уже согласны и на C++. Тем более что его последние стандарты сильно продвинулись по вопросу безопасности памяти.
Откуда вообще взялось это ограничение на язык для ядерных модулей? Сишные интерфейсы и структуры они же в любой язык встраиваются на in/out на раз-два. Почему нельзя скомпилять ядерный модуль на с++, zig, rust да на любом язяке. Не понимаю.
> Откуда вообще взялось это ограничение на язык для ядерных модулей? Сишные интерфейсы и структуры они же в любой язык встраиваются на in/out на раз-два. Почему нельзя скомпилять ядерный модуль на с++, zig, rust да на любом язяке. Не понимаю.* Нужна поддержка сбоки модулей на другом языке.
* Нужно выработать единый интрефейс для модулей на языке.Сейчас ядро про эти языки ничего не знает. Вот если сделать чтобы модули можно было писать независимо на любом языке. Насколько я понимаю для WASI (https://wasi.dev/) - это одна из целей.
>Вот если сделать чтобы модули можно было писать независимо на любом языкеВот поэтому высокоуровневых программистов и веб-мака* нельзя подпускать к системному программированию. У них мышление не нормальное.
>>Вот если сделать чтобы модули можно было писать независимо на любом языке
> Вот поэтому высокоуровневых программистов и веб-мака* нельзя подпускать к системному программированию.
> У них мышление не нормальное.Что плохого в идее WASI?
Я зол. В низкоуровневых разработках нет места объектно-ориентированным языкам. Си плюс-плюс запретить. Всё! Такие вопросы вообще не должны обсуждаться.
Но поскольку разработчикам ядра Linux виднее, что им делать, обсуждение перехода ядра на C++ продолжается, а ты можешь и дальше писать свои бессильные гневные комментарии.
> Я зол. В низкоуровневых разработках нет места объектно-ориентированным языкам. Си плюс-плюс
> запретить. Всё! Такие вопросы вообще не должны обсуждаться.Да ладно бы ОО. C++ даже как ОО не очень. Просто страшное недоразумение какое-то. Сложный, запутанный и кривой.
Не тролинга ради вопрос: в каком языке ООП сделано как надо?
Нормальное ООП должно быть основано на интерфейсах. Никакого наследования. Тем более множественного. Более-менее нормальное ООП в Java.
>Никакого наследования.Да ты чё, сам придумал? Но тогда почитай, на каких столпах основано это самое ООП.
> Не тролинга ради вопрос: в каком языке ООП сделано как надо?smalltalk, от автора термина ООП. Erlang. Что ещё хз. Это из того, что видел. C++ и Java точно не из этого. Но в java хотя бы насколько смогли улучшили ситуацию по сравнению с C++, выкинув некоторые извращения и ненужные усложнения.
>> Не тролинга ради вопрос: в каком языке ООП сделано как надо?
> smalltalk, от автора термина ООП. Erlang. Что ещё хз. Это из того,
> что видел. C++ и Java точно не из этого. Но в
> java хотя бы насколько смогли улучшили ситуацию по сравнению с C++,
> выкинув некоторые извращения и ненужные усложнения.Набор микросервисов с динамической типизацией. В качестве примера ООП это лучше не приводить. Он был первым, который вступил на тропу. Но свернул совсем не туда.
В Java поправили diamond problem, зато напихали default interface. Отличие абстрактного класса от default interface теперь не многие назовут.
А вы эти static utils *anything видели. Анемичные модели. Это разве похоже на ООП? Типичный процедурный стиль уровня C, с той разницей что все функции должны в классах лежать.
> В Java поправили diamond problem, зато напихали default interface. Отличие абстрактного
> класса от default interface теперь не многие назовут.
> А вы эти static utils *anything видели. Анемичные модели. Это разве похоже
> на ООП? Типичный процедурный стиль уровня C, с той разницей что
> все функции должны в классах лежать.Кто ж сказал, что java идеальна? C# в этом плане получше, по свидетельствам очевидцев.
Например, в D (чистый преемник С++). Нет множ.наследования (порождающие больше проблем, чем решающие). Есть traits. Шаблоны. Да вообще ВСЁ, что может понадобиться адекватному ООПщику - чего не пишется, спрашивается??
> Нет множ.наследования (порождающие больше проблем, чем решающие).Тут только одна проблема - это самое порождение проблем родит их для разработчика языка. Пользователя этого языка эти проблемы не должны касаться. Для пользователя это звучит как: "Ну не смогла я, не смогла".
Что ж людям-то не работается спокойно. То rust с его кошмарным синтаксисом, то C++ - кромешное нагромождение всего и вся - пытаются запихнуть в ядро. Ёплки-палки, да работайте просто уже. Хернёй не страдайте.
>C++ - кромешное нагромождение всего и всяЯ слушал интервью Страуструпа. Он сам хотел этого - язык в котором есть всё в виде объектов.
>>C++ - кромешное нагромождение всего и вся
> Я слушал интервью Страуструпа. Он сам хотел этого - язык в котором
> есть всё в виде объектов.Дело не в том, что там всё в виде объектов. Дело в том, что там просто кошмарный ужас из всего. Если хочется ООП, то надо смотреть на другие ЯП. C++ это не ООП. Это наркоманский приход. И да, есть интервью Страуструпа, где он признаётся, что хотел ЯП замороченный настолько, что бы у работодателя не вызывало вопросов требование больших ЗП тем, кто несмотря ни на что в этом кошмаре разберётся. Он добился своего :-). Но мы этим пользоваться не обязаны.
> И да, есть интервью Страуструпа, где он признаётся, что хотел ЯП замороченный настолько, что бы у работодателя не вызывало вопросов требование больших ЗП тем, кто несмотря ни на что в этом кошмаре разберётся.Можно ссылку?
В книге The C++ Programming Language, 4th Edition, подчеркиваеться что Страуструп, никогда не говорил что язык C++ это ООП язык, цитируюI wince when someone characterizes C++ exclusively through one of these styles (e.g., ‘‘C++ is
an object-oriented language’’) or uses a term (e.g., ‘‘hybrid’’ or ‘‘mixed paradigm’’) to imply that a
more restrictive language would be preferable. The former misses the fact that all the styles men-
tioned have contributed something significant to the synthesis; the latter denies the validity of the
synthesis. The styles mentioned are not distinct alternatives: each contributes techniques to a more
expressive and effective style of programming, and C++ provides direct language support for their
use in combination.дальше можно не читать этот жирный троллинг.
>> И да, есть интервью Страуструпа, где он признаётся, что хотел ЯП замороченный настолько, что бы у работодателя не вызывало вопросов требование больших ЗП тем, кто несмотря ни на что в этом кошмаре разберётся.
> Можно ссылку?Не могу найти оригинал. Перепечатка тут: http://harmful.cat-v.org/software/c++/I_did_it_for_you_all . Хз насколько это троллинг, но, зная C++ в сравнении с другими ЯП, охотно воспринимается за чистую монету.
Майкрософт вот не тупит и на расте уже Винду переписывает: https://www.theregister.com/2023/04/27/microsoft_windows_rust/А комментаторы опеннета всё живут умом где-то в в 90-ых.
Приводить Майкрософт (компанию, которую все презирают), как пример для подражания. Ну, это даже не шутка, это жирнейший троллинг.
То, что в M$ работают индусские м@к@ки, порождает и соотв. решения - вот Раст к примеру :)) Абсолютно необоснованное решение. Как и попытки заигрывания в Линукс внутри венды.
Сейчас M$ далеко не "гигант ИТ" - это монстр, который полностью сгнил внутри и идёт чисто как зомби - по инерции. Венда-10-11 - это очевидный тупик, забагованный больше алкашного дивана. .NET Core движется в ___еня. Студия не развивается толком, т.к. требуется ПОЛНОЕ переписывание.
На плаву держатся серверные системы и MS SQL (видимо, обезьян не подпускают к золотой курице).Другими словами, найдите пример поинтереснее.
> внутри и идёт чисто как зомби - по инерции. Венда-10-11 -
> это очевидный тупик, забагованный больше алкашного дивана. .NET Core движется в
> ___еня. Студия не развивается толком, т.к. требуется ПОЛНОЕ переписывание.Да это вы просто не видели что они с виндофоном вытворяли. Еще и нокию за собой утопили, угробив все наработки UI/UX от нокии, с...ки!
Заскорузлые мозги => устаревшие решения.Почему не D ?? Для кого развивали "преемника С++"? Там же всё по-уму сделано, а популяризация его в линукс-камьюнити только ещё больше поможет языку.
Если бы его грамотно пиарили и больше людей в разработку включили, а так имеем что имеем. Но он еще вполне жив, так что посмотрим.
Вкатывающимся ядроразрабам помимо знания сишки нужно будет отлично знать кресты с их шаблонной магией и прочими непотребствами стандарта на много тысяч страниц. Таким образом резко повышается порог вхождения.
С++ и С имеют множества недостатков от которых некоторые современные языки вылечены. Проблема в том что разработчики компиляторов и железа в первую очередь поддерживают С,С++ и в стандартизации — разных поставщиков и наборе инструментов. Поэтому выигрывает тот язык, который сумеет буквально его поглощать трансляцией в другой язык. Таких пока вроде нет и вряд ли будет — из-за множества ньюансов дешевле нанять команду разработчиков которые будут переводить из С на свой язык библиотеки и фреймворки. А вот локальные миссии по созданию цифровой экосистемы могли бы дать результат, если целенаправленно двигаться лет так 10–15. Но миссии это у американцев, потому что у них agile процессы.
Поток сознания