- Дискуссия об использовании языка C++ для разработки ядра Lin..., _kp, 23:42 , 14-Янв-24 (62) –24 [V]
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 00:03 , 15-Янв-24 (75) +2
О чем речь? С++ может инициализировать структуры
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 00:07 , 15-Янв-24 (78) +1
struct A { int a; int b; };A a1{1, 2}; работает в C++20 (может и в более ранних версиях)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _kp, 11:30 , 15-Янв-24 (244) –1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 13:43 , 16-Янв-24 (513) +2
> a1{1, 2}; > Вот не надо подобного. Когда полей в структуре не один десяток, получим > нечитаемый говнокод и хорошими шансами на вагон опечаток.И хотя это правда, стоит добавить: когда в структуре столько полей - мы знаем что программер/архитект где-то сказочно облажались. Когда у вас столько полей, линейным списком, вы что-то сделали не так. Что, даже вложенный struct не смогли? Или это и правда плоский список такого размера? Что бы это могло быть в легитимном виде, когда того кто это сделал не надо бы уволить с треском за вот это все?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 14:32 , 16-Янв-24 (525) +1
Начнём с того, что вложенные структуры конкретно данную проблему не исправят, а только добавят скобочек в визуально случайных местах инициализации структуры.Продолжим тем, что глупо добавлять структуры только для того, чтобы уменьшить число полей в каждой из них. Это вам не Ява, где шаг вправо-шаг влево - и у вас сонаркуб заругается, что в структуре больше двух полей, давайте, разбивайте на несколько структур, даже если смысла в этом нет, просто первую половину полей в одну структуру, вторую половину - во вторую. И закончим на соседней новости, где просто изменением порядка полей в большой структуре добились увеличения производительности на 40%. В случае со вложенными структурами эта оптимизация была бы где-то в диапазоне от "выглядит бредово" до "это невозможно".
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:18 , 19-Янв-24 (644) +1
> Начнём с того, что вложенные структуры конкретно данную проблему не исправят, а > только добавят скобочек в визуально случайных местах инициализации структуры.Вообще-то сделают данные более структурированные - и - вот - менее подверженными тому классу ошибок. Если вы это не понимаете - что я там про архитектов то говорил? Вывалить более 9000 сущностей линейным списком не больно какая архитектура. > Продолжим тем, что глупо добавлять структуры только для того, чтобы уменьшить число > полей в каждой из них. Это вам не Ява, где шаг > вправо-шаг влево - и у вас сонаркуб заругается, Ну так правильно заругается. Нефиг гамнокодить. Структуры с дохреналионом полей уж точно не признак мастерства архитекта и изящества архитектуры. > что в структуре больше двух полей, давайте, разбивайте на несколько структур, > даже если смысла в этом нет, просто первую половину полей в одну структуру, вторую > половину - во вторую. Со своей стороны я буду считать что более ~десятка полей в структуре - "кодер был неадекватен и делал какую-то фигню или не смог в архитектуру, гамнякая в режиме питоняши". > И закончим на соседней новости, где просто изменением порядка полей в большой > структуре добились увеличения производительности на 40%. А вот там господа таки - понимают что делают - и структур с более 9000 полей не заводят. И вложенные структуры юзать не гнушаются. Такая ерунда. > В случае со вложенными структурами эта оптимизация была бы где-то в диапазоне > от "выглядит бредово" до "это невозможно". С чего бы это вдруг? А 1 из примеров - заменили struct на u32. Стало даже проще. На самом деле есть tradeoff между нуждами оптимизации кода и изящностью и логической консистентностью апи. Не всегдя изящное логичное апи хорошо маппится на конкрерику оптимизера вот тут. Тот кто не джун и уже умеет в архитектуру и управление проектом немного - понимает что нужен какой-то разумный баланс. Если у вас более 9000 полей в структуре, очевидно, это профачено.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _kp, 20:06 , 16-Янв-24 (578)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:33 , 19-Янв-24 (645) +1
> Что значит мы? Это задачи такие. Ну да, вы такие особенные на всю планету, наверное. > И не все делается в одиночку. Значит общее управление проектом оставляло желать. То что факап по чуть другой линии не означает что это офигенная идея и так и надо было. > Что требуется для работы с устройствами и протоколами. > А в итоге, иногда, строки в исходнике распухают за 400 символов. ;) Типа, когда это УГ надо скроллить даже на здоровенном мониторе - намного понятнее и читабельнее? Более того - это нехило ограничений на конфиги тех кто в проекте будет копаться. В опенсорсе чревато тем что вам вообще патчей не пришлют, решив что скроллякать ваши простыни на вон том лаптопе - нафиг надо, лучше другой код взять, менее отшибленый. > Отформатируешь, так будет каша, в которой не разобраться. ORLY? У меня другие идеи на этот счет. Сорри. В случае опенсорса, если я где-то такое встречу, я просто немедленно сотру это как непотребное, если есть замена, или жестко отрефакторю, если по другому совсем никак. Потому что такой гамнякинг для меня приемлимым не является. > Впрочем, что где то плохо спроектировано я соглашусь. Матерюсь же. ;) Ну дык, иногда бывает что ну вот оставляет желать, но это ж не пример как надо делать. А пример как делать НЕ надо. Чтобы другие потом не матерились на такой код.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 00:42 , 15-Янв-24 (90) +1
> Пока с++ не осилит инициализацию структур, говорить о переносе кода безполезно, ибо > сизифов труд.Эй, это даже в си работает?! Вы там что-то совсем тормоз не отпустили? Черт, даже можно присваивать однотипные структуры. Одна из причин по которым gcc в freestanding надо memcpy - конечно же такое присвоение это вот оно будет.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:23 , 15-Янв-24 (115) +5
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 03:49 , 15-Янв-24 (149) +1
a = {.x = 1, .y = 2};
Вот такой синтаксис завезли только в 20е плюсцы.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _kp, 11:55 , 15-Янв-24 (249) +3
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 14:35 , 15-Янв-24 (305) +1
> Принципиальная разница инициализации структур с Си,в том что это и занимает 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++ для разработки ядра Lin..., _kp, 11:37 , 16-Янв-24 (505)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., adolfus, 20:24 , 16-Янв-24 (581)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 04:04 , 17-Янв-24 (599)
> Вы предлагаете в структуры напихать методов на все случаи?Я лишь констатировал что на си можно делать весьма по разному - в том числе даже и фокус на манер конструктора, вот, отколоть. Иногда даже может иметь свой пойнт. Нужно ли делать именно так в конкретном случае - на усмотрение програмера. > удобно же, и читаемо. :) Ну извините, в сях в общем случае принято допустим 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.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 16:29 , 15-Янв-24 (341) +1
> Принципиальная разница инициализации структур с Си,в том что это и занимает 0 тактов, в отличии от конструкторовА можно пример, чтобы это было так не только с -O0? Зачем компилятору вызывать конструктор, когда он может применить оптимизации? Можно этот переделать: https://godbolt.org/z/Y4G554zdr
- Дискуссия об использовании языка C++ для разработки ядра Lin..., pavlinux, 17:21 , 15-Янв-24 (352) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., ДаНуНафиг, 18:29 , 15-Янв-24 (367)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:45 , 15-Янв-24 (373)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _kp, 02:31 , 16-Янв-24 (471)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:47 , 16-Янв-24 (474)
> constexpr variable must be initialized by a constant expression На сях для тактов вы тоже либо скроите эквивалентное по смыслу, либо это не 0 тактов получится. За 0 тактов только то что удалось в константу сколлапсить, для чего оно должно быть вычисляемо на этапе компила. Иначе фиг тебе, золотая рыбка.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _kp, 10:13 , 16-Янв-24 (492)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 04:09 , 17-Янв-24 (600)
> constexpr и задумано для этого. Не спорю. > Но где то не применимо. Хотя в большинстве случаев и предпочтительнее и мощнее.Как бы плюсы мощнее сей. Но если повыпендриваться - то си можно основательно перекроить. Но не факт что нужно, ибо огорошивать посторонних кодеров экзотичным диалектом... не очень хорошая идея. Хотя о C++ ходит даже в общем то и не шутка что каждый програмер пишет на своем диалекте C++. > Смысл пожеланий о ициализации, в том, что бы с++ компилятор переваривал исходники > Си без их правки. На 100.0% это все же врядли получится. Скажем "register" в C++ нету. И auto означало нечто совсем другое до недавних пор. Хоть я и не понимаю чем им "register" так уж не угодил. > Это не тяжелое изменение. А переезд могло бы сильно облегчить. Вот конкретно там я тоже не понимаю почему вообще должно быть такое отличие.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., ДаНуНафиг, 16:29 , 19-Янв-24 (642)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., InuYasha, 00:03 , 16-Янв-24 (450)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., анон, 16:27 , 16-Янв-24 (554) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 11:16 , 15-Янв-24 (236)
> ибо сизифов трудЕсть же знатоки.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., leap42, 12:57 , 15-Янв-24 (270) +2
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 21:43 , 14-Янв-24 (1) –17 [V]
Нельзя туда цпп. Ладно модули, только не ядро. Запаримся пересобирать же! Си собирается намного шустрее.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., oficsu, 21:46 , 14-Янв-24 (2)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:08 , 14-Янв-24 (18) +3
>Там жалобы есть в том числе на макросы. А они вполне себе могут компилиться дольше, чем какие-нибудь шаблоны, решающие ту же задачуШТО? Макросы, в отличие от шаблонов цпп, не обладают тьюринговой полнотой. Это шаблоны можно заставить компилироваться сколь угодно долго.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., funny.falcon, 23:20 , 14-Янв-24 (52) +3
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:41 , 14-Янв-24 (61) +4
> Я сделал на шаблонах довольно мощную штуку с объектным программированием на C. > И оно компилится действительно очень долго.А я сделал себе верификацию ряда операций в компилтайме, скажем что я в 32 бит регистре не трогаю 35-й бит. Почти хруст получился. Даже не тормозит особо. В сабже кстати есть зачатки этого добра откуда я и содрал идею. Хотя круче всего это в Zig сделано - там можно компил тайм предвычисления юзая стандартный синтаксис яп. Плюсы в этом смысле - убогие полумеры, ибо препроцессор с отдельным синтаксисом никуда не делся. А какой-нибудь constexpr знатный горбыль так то.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:32 , 14-Янв-24 (56) –1
> Макросы, в отличие от шаблонов цпп, не обладают тьюринговой полнотой. > Это шаблоны можно заставить компилироваться сколь угодно долго.Они ну вот буквально на грани :). Единственный лимит - рекурсия до 128, чтоли, уровней в GCC разрешена. Но с таким количеством рекурсии можно основательно позажигать.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., oficsu, 23:48 , 14-Янв-24 (69) –1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Bottle, 22:29 , 14-Янв-24 (30) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 21:47 , 14-Янв-24 (4) +5
Так пусть определятся для начала. Если rust можно, то почему плюсы нельзя?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 21:50 , 14-Янв-24 (6)
А сколько там модулей в стандартной библиотеке, которые меняются из версии в версию (просто как вот это всё дебажить потом на уязвимости, если ядро на C уже вселенского масштаба)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 21:50 , 14-Янв-24 (7) +1
Даже в Gentoo завезли бинарное ядро.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:43 , 14-Янв-24 (36)
Для истинных гентушков это ничкго не изменило.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:02 , 15-Янв-24 (105)
Как будто только гента позволяет ядро пересобрать. В Void это делается ровно точно так же с конфигом ядра без всяких use флагов.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 00:06 , 16-Янв-24 (452) +2
Так сборка ядра в Генте ничем не отличается от сборки в других Линуксах. Неиспользуются при этом флаги USE. Только вот линуксоиды ныне измельчали, не собирают себе ядра. А потом ноют, что им такое жирнючее положили в дистр.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 13:49 , 16-Янв-24 (517)
Отличается же, в генте не нужно готовить всякий шлак вроде initrd и не нужно собирать всё ядро. В других линуксах всё же обычно дают возможность пересобрать всё и это очень долго, а ксатомизировать крайне геморно
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 04:16 , 17-Янв-24 (601)
> Отличается же, в генте не нужно готовить всякий шлак вроде initrd и > не нужно собирать всё ядро. В других линуксах всё же обычно > дают возможность пересобрать всё и это очень долго,Yolo! Я майнлайне кернель под дебианом собираю. В билдсистеме ядра даже есть генерация пакетов. Таргет "make bindeb-pkg" - и билдсистема сама скроит пакетик с кернелом в лучшем виде. И да, часть систем тоже взлетает без initrt. Хоть они и дебианы. Что в этом такого? И уж конечно кастомизировать можно все что угодно. Билдится это - в зависимости от того что включено. Только билдить кернел для 1 тазика не совсем практично - для какого-то "класса железок" намного прагматичнее. Ибо майнтайнить зоопарк - затея весьма голимая. Особенно как локалхостов становится более десятка. > а ксатомизировать крайне геморно Я бы не назвал menuconfig чем-то ужасным. А вон там для референса дистровский конфиг есть например. И гемор - он в чем? И чего так уж упрощает в этом гента? Там самое сложное - это понимать что эти галочки реально делают. Гента в этом не поможет вообще никак :)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 16:35 , 17-Янв-24 (623)
> А вон там для референса дистровский конфиг есть например. И гемор - он в чем? Тем, что этот конфиг слишком избыточный и проще начать всё делать с нуля. Сложность заключается в кол-ве телодвижений от начала процесса и до выкатки в бутовый конфиг за вычетом времени в menuconfig
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:46 , 19-Янв-24 (647)
> Тем, что этот конфиг слишком избыточный и проще начать всё делать с нуля.ИМХО где как. На десктопе я от дистровского конифига танцевал, таргетируя более-менее похожие на мой компы x86-64, без совсем редких вундервафель махрового энтерпрайза или винтажного добра редко встречающегося в x86-64. Да, кернел жирнее и дольше билдится. Зато подымает 3 мои компа включая "альтернативные/бэкапные" и ноут. Без затрат времени на билдовку им уберкастома. Это осознанный tradeoff. А например на ARM - я местами и от мелкого defconfig оттанцевал. Потому что вот там из дистрокернела вырезать ненужное можно и заманаться уже, если я таргетирую допустим пяток похожих железок на чипах одной фирмы и более - нифига. > Сложность заключается в кол-ве телодвижений от начала процесса и до > выкатки в бутовый конфиг за вычетом времени в menuconfig Когда тазиков оказывается не 1 а эн, начинает хотеться некоторого обобщения оных и урезания объема работ. Если у меня легион одноплатников - и я буду каждому кернел под микроскопом пилять - я тогда займусь только микро-оптимизациями, а на более полезные и интересные проекты времени не останется. И вот интеерсные проекты будут спущены в угоду 2% перфоманса. А оно того точно стоило? Эти 2% никто не заметит - и я уж точно не упирался в 2% перфоманса в задачах которые там были. Иначе я бы выбрал более мощную железку, для более разумных сроков проекта.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., maximnik0, 21:51 , 14-Янв-24 (8) –1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:43 , 14-Янв-24 (63)
> Так разговоры давно идут об введений подмножеств - урезанной современной версии языка. > С выкидыванием всякого хлама,там такого всего накопилось ......Так то g++ заметно тормознее gcc... потому что C++ куда как более фичастый язык. И время жевания сорцов на плсоте - ну вот реально заметно дольше. Хоть там как.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 00:13 , 16-Янв-24 (458) +2
И чё? Когда сам GCC c версии 4.8 тоже начал постепенный переход на C++, тоже ныли, мееедленно. Вот спустя десяток лет, полёт нормальный. Пользуемся и не замечаем. Уж некоторые и забыли/не знали, что он на C++.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:52 , 16-Янв-24 (475) +1
> И чё? Когда сам GCC c версии 4.8 тоже начал постепенный переход > на C++, тоже ныли, мееедленно. Вот спустя десяток лет, полёт нормальный. > Пользуемся и не замечаем. Уж некоторые и забыли/не знали, что он на C++.А вы часто вот именно gcc сами компилите, чтобы разницу в времени компила gcc ощутить? Так то его заметно тормознее себе перекомпиливать стало. Я это еще и практикую, так что знаю о чем говорю. На скорость работы скомпиленой прогрыммы это может и не влиять. А вот на скорость компила очень даже. Ну и вот проги на плюсах - заметно дольше компилятся "при прочих равных" (e.g. примрено одинаковая функциональность).
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _kp, 21:47 , 16-Янв-24 (583)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 04:30 , 17-Янв-24 (603)
> А сейчас что скорость компиляции примерно одинакова, с очень небольшим преимуществом 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 после того как разрешили юзеж плюсов пересобираться стал ощутимо дольше, что в общем то и не фича вовсе.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _kp, 12:26 , 17-Янв-24 (615)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 16:53 , 21-Янв-24 (673)
> Впрочем, раз Вы вполне опытный, можете собрать и сами. А если "Васяны" > дали подсказку куда копать, то и их труды не пропали.Я ESP не использую, и врядли буду когда либо. Так что это знание может и будет полезно... но кому-то другому. > Малый разрыв в скорости, это когда си-исходник собирается с++ компилятором. Вы издеваетесь? Меня жонглирование цифрами не интересует, интересно время фактической сборки проектов. Зачем мне обманывать самого себя? И в этом смысле плюсовые проекты заметно тормознее билдить. > Ещё на слабых для разработки компах, и тем более каких есть ноутбуках, > свежие компиляторы в принципе медленнее старых версий их же самих. И > разрыв между компиляцией си и с++ будет вполне заметен. А на > среднемощном десктопе таки пофиг. У меня довольно мощный десктоп - и - боюсь я очень даже вижу разницу в времени билда старого gcc и нового где плюсоту можно стало, например. А по сравнению с кернелом gcc так то довольно небольшой проект. Заякорить билд кернела в пару раз было бы очень такой себе идеей. На разлапистой конфиге там и так время билда очень даже.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _kp, 19:21 , 21-Янв-24 (674)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 20:34 , 21-Янв-24 (675)
> Как нас унесло. Изначальный смысл был скормить си исходники компилятору с++, а > не переписывать, чем занята другая группа.Вот те раз. А я то думал изначальный смысл - оценить технологию, по возможности объективно и непредвзято. И в этом смысле меня таки как кастомщика и кернелбилдера в контексте сабжа беспокоит потенциал для обвала скорости компила в разы. Да, C++ позволяет более выразительные конструкции. Если б еще наслоения легаси выкинуть, и оформить более безопасный subset дефолтов "для чайников" - был бы наверное неплохой яп так то. Но в случае с проектом размером с кернел есть много разных аспектов. Время компила напрямую влияет на допустим степень протестированности кода, да и скорость разработки якорит. Не, коду который "haven't seen compiler" я не доверяю. Never had, and never will. > Мощные десктопы на работе, и дома у любителей. У меня тоже есть и мощные. Времена билда кернела могут напрячь и на таких. Помножить эти времена на эн - очень так себе идея. К тому же это все создает entry level barrier там где его быть не должно, отсеивая всяких студентов и ко. Зачем нам это проект без студентов и энтузиастов, где только мегакорпы? > Но случаи бывают разные. Банально что то поправить, и собрать не дома. > Есть ещё командировки. И студенты в конце концов. Ну дык. Чем злее требования к конфиге - тем меньше народа это все будет делать. Это идет вразрез с идеями опенсорса - и куда это заведет? К тому что пилить будут полтора корпората с билдфермами? Так что совсем игнорить этот топик имхо не стоит. >>>плюсовые проекты заметно тормознее билдить. > Плюсовые, да, там же тупо язык сложнее. Но не такая редкость когда > по сути си проекты, с минимумом фич от с++, или их > отсутствием, собирают с++ компилятором. Это в основном майкрософтовские кодеры таким страдают, как и юзежом си++ в режиме "чуть улучшеный си". Вызвано убогостью MSVS как си компилера, но в случае сабжа не аргумент ибо - unsupported config. > И тут, взависимости от стиля исходника, бинарник может получиться и лучше, С фига ли вдруг? > и контроль типов получше, Да вообще-то в сях он весьма даже. А если кто думал что знает о типах все, пусть попробует -Wconversion поюзать. И таки - компилер то может. А вот сможете ли вы с этим жить, если вам на pre-existing проекты вот такие жесткие проверки влепить... > Вообще, если не рассматривать ядро, то гораздо чаще сборку проекта можно ускорить > не заменой компилятора, а его реорганизацией проекта, зависимостей, и правилами сборки, Ну да, давайте искать не там где ключ потеряли, а под фонарем, потому что там светло. Вон то все же похоже на костыль или неизбежное зло, которым занялись от отличной скорости сборки плюсоты. Это конечно не оправдание для совсем уж хреновых подходов. > а то именно на мощных компах проекты "начинающих" и "консерваторов" не > используют все ресурсы компа, и даже на мощной машине собираются неспешно. Да вообще-то при пинке в кучу потоков процы оно нормально жрет и как раз упирается в именно проц. Вот особенно - плюсота как раз. Там именно g++ плотно проц грузит надолго, в остальное захочешь не упрешься. На сях там еще может быть всякий оверхед, io и проч, т.к. относительно резво билдует. Но в плюсах это как раз намного меньшая проблема.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:12 , 14-Янв-24 (20) +4
А зачем вы его постоянно пересобираете?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:46 , 14-Янв-24 (40) +3
2.6.32 работает - не трожь!
- Дискуссия об использовании языка C++ для разработки ядра Lin..., anonymous, 23:39 , 14-Янв-24 (60)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 00:06 , 15-Янв-24 (77)
> А зачем вы его постоянно пересобираете?Потому что его постоянно правят. Вот бы заморозили его разработку, да? Тогда можно было бы переписывать на любые языки и не заботиться о том, что кто-то захочет его собрать.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., pv, 13:23 , 15-Янв-24 (277) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:27 , 14-Янв-24 (27) +2
опять огульные выдуми кро скорость сборки. когда же вы успокоитесь, выдумщики
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:40 , 14-Янв-24 (34) +1
>Запаримся пересобирать же! Си собирается намного шустрее.А что вы про Rust запоёте?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 21:46 , 14-Янв-24 (3) –11 [V]
> В списке рассылкиШёл 2024 год...
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 21:47 , 14-Янв-24 (5) –5 [V]
П.с. Так там ещё и 80 символов ограничение 🤦♀️
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 21:53 , 14-Янв-24 (9) +5
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:57 , 14-Янв-24 (72) –3
Отличное ограничение, ещё бы TABы сделали равными 4м символам или вообще заменяли бы их на пробелы
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:37 , 15-Янв-24 (118)
А лучше трем символам. Или может восьми, видел и такое.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 14:03 , 15-Янв-24 (296) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 14:58 , 15-Янв-24 (313)
Яваскриптеры голосуют за два пробела.В общем, после окончания споров "табы/пробелы" появляется множество других интересных и продуктивных споров на тему того, сколько именно пробелов использовать. Таким образом, находится и работа для тех, кому код писать не получается, а поучаствовать в разработке охота.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 13:49 , 15-Янв-24 (291) +1
Лучше пробелы, тогда форматирование не зависит от настроек редактора кода и, следовательно, не едет.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., rmh, 14:34 , 15-Янв-24 (304) +2
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 14:52 , 15-Янв-24 (311) –2
> не зависит от настроек редактора кода и, следовательно, не едет.Ложь. Едет, если в редакторе настроена замена пробелов табуляциями. То есть от настроек редактора зависит.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 19:14 , 15-Янв-24 (391) +1
едет, если умственно-ограниченные начинают использовать табуляцию не для индентификации кода (и использовать этот символ строго в начале строки до первого не-пробельного), но и пытаются табуляцией что-то форматировать в середине строки.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 15:01 , 15-Янв-24 (315)
Вы бредите. Табуляция - это табуляция, ОДИН символ. Что значит "равной 4 символам"?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 15:17 , 15-Янв-24 (321) +2
TAB это терминальный опкод, а не символ. Ровно как и все ASCII символы до 0x20 не символы.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., VladSh, 18:50 , 15-Янв-24 (376) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., InuYasha, 00:07 , 16-Янв-24 (453)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:55 , 16-Янв-24 (477)
> когда я в подном большом проекте заменил все отступы на табы (вместо > 4 пробелов) и \r\n на \n, сэкономилось несколько МАГАБАЙТ. И это > всё каждый раз парсилось ИДЕ, компилятором, гитом, архиватором...А еще на несколько мегов меньше читать и парсить (компилеру whitespaces до лампочки, это ж не питон). Тоже так то аргумент.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 06:37 , 16-Янв-24 (482) +1
Производительность взлетела до небес, наверное.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 13:53 , 16-Янв-24 (520)
Что такой тугой, TAB равен изначально 8-и символам и это неудобно. Что породило со временем кастомные настройки размера TAB-ов, например, более практичный 4 символа. И по факту теперь это плаваяющая единица из-за чего при разных настройках едет форматирование текста. Потому TAB в современном мире непригоден для использования. Ситуацию можно починить если вхерачить в UTF специальные коды для TAB-ов разного размера или же инструкцию с заданием длины TAB-ов.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 14:56 , 16-Янв-24 (531) +1
Ещё раз, специально для вас.Форматирование при использовании табов едет только у тех, кто между табом и пробелом выбирает, бросая игральные кости. У тех, кто использует табы только для отступов, ничего не едет, а изменение размера табуляции позволяет сделать код более читабельным: кому-то комфортнее 8 столбцов в отступе, кому-то 2.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 17:52 , 16-Янв-24 (565)
Какой и ты тугой. Форматирование в общем случае едет всё равно потому что TABы конкурируют с обычным текстом в соседних строках. Например, это разбивка длинных аргументов у функций на строки, это многострочные комментарии с развёрнутыми пояснениями, это идиотский GNU стиль расстановки скобочек {. И многое другое.> а изменение размера табуляции позволяет сделать код более читабельным: кому-то комфортнее 8 столбцов в отступе, кому-то 2. Галиматью несёшь. Код сразу форматируется под конкретный размер TABа и с другими размерами форматирование едет
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _kp, 22:00 , 16-Янв-24 (584)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., nich, 21:58 , 14-Янв-24 (10)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:05 , 14-Янв-24 (16)
... и до сих пор не придумали ничего лучше, чем форум. Даже в виде рассылки.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:12 , 15-Янв-24 (109) +4
Подозревая, что в 2044 половина модных сервисов позакрывается, а списки рассылки и их архивы будут на месте.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Тот_Самый_Анонимус_, 05:36 , 15-Янв-24 (160) –1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 21:59 , 14-Янв-24 (11) +3
> "Now, "why not Rust"? First of all, Rust uses a different (often, in my opinion, gratuitously so) syntaxЭто он ещё очень дипломатично выразился относительно этого нагромождения сокращений и спецсимволов.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 00:13 , 15-Янв-24 (81) –5 [V]
А какая тебе разница, какие там спецсимволы? Тебе алгоритмы писать, а не буковки разглядывать. Так что пофиг какой в языке синтаксис, это вопрос десятый. Если уж так хочется - можно и DSL написать с другим синтаксисом.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Витюшка, 01:35 , 15-Янв-24 (100) +8 [^]
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:57 , 16-Янв-24 (573)
> Код должен ясно передавать намерения (высокоуровневые) и идеи алгоритма.Нет. Код должен реализовывать алгоритм, который описан обычным человеческим языком в комментарии прямо перед ним, а реализация должна быть обязательно аннотирована ссылками на это описание и, по необходимости, прокомментирована. В случаях когда реализация использует оптимизации (например, специфические для ЯП или аппаратной платформы), они обязательно должны быть прокомментированы с описанием оснований для принятия решения об оптимизации, списком рассмотренных альтернатив, результатами бенчмарков и снабжены тестами, эти самые бенчмарки реализующими. В противном случае действительно можно и на brainfuck писать с тем же успехом.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 07:22 , 15-Янв-24 (170) +3
Код гораздо чаше нужно читать, чем писать. Поэтому, чем удобнее его читать, тем лучше. Си в этом плане кстати тоже не идеал, но определённо лучше Rust и C++.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Советский инженер, 09:55 , 15-Янв-24 (197)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., adolfus, 20:33 , 16-Янв-24 (582)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 08:27 , 17-Янв-24 (609)
>Что касается goto, то без него вы даже из вложенного цикла не выйдете. Что касается "обычных непричин", нон-секвитуров и прочих нерелевантных доводов, выходы из вложенных циклов просто свидетельство каши в коде и в голове разраба. >Вернее, выйдете, но через виртожопу. Из через жопу написанного кода любой выход только такой. И с помощью goto в первую очередь.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 08:32 , 17-Янв-24 (610)
>Что касается goto, то без него вы даже из вложенного цикла не выйдете."Cache-friendly программирование? Не, не слышали." И продолжили выходить из вложенных циклов... А главное, писать вложенные циклы.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., warlock66613, 19:53 , 15-Янв-24 (397)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., scriptkiddis, 10:01 , 16-Янв-24 (490)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 11:47 , 15-Янв-24 (248) +4
Так сокращения это норма для линукса. cp, mv, dd, rm, ls, df, du, pz
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 12:45 , 15-Янв-24 (258)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 15:05 , 15-Янв-24 (316) +2
Могу назвать ещё минимум две причины, по которым ls -l Лучше, чем list-files-and-directories --show-as-much-details-as-possible
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:59 , 15-Янв-24 (382) +2
> Могу назвать ещё минимум две причины, по которым > ls -l > Лучше, чем > list-files-and-directories --show-as-much-details-as-possible Вы только что рассказали почему powershell - ацтой каких мало. Ах да, автодополнение в том уродце не работает по сути никак, чтобы вы уж точно сломали пальцы. Как-то так и понимаешь где индусы, а где гении.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 19:24 , 15-Янв-24 (393) +1
Наоборот же, powershell показывает, что можно всем угодить изкоробочными алиасами и parameter name matching'ом (-def ниже, как одна из недвусмысленных подстрок, с которых начинается параметр -Definition).> get-alias ls Alias ls -> Get-ChildItem > get-alias -def get-childitem Alias dir -> Get-ChildItem Alias gci -> Get-ChildItem Alias ls -> Get-ChildItem
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:57 , 15-Янв-24 (446)
> Наоборот же, powershell показывает, что можно всем угодить > изкоробочными алиасами и parameter name matching'омОн мне так угАдил своим синтаксисом, километровыми командами и очешуенным временем старта на виртуалках что я как раз и развидел маздайку к хренам. И назад уже никогда не вернусь, хоть там что. Простите но какую задачу решает (ba)sh я понимаю. Какую задачу решает это индусское месиво я не понимаю. Мне такой шелл - без надобности. Совсем. Одно это уже бьет наповал ваше "всем" наличием конкретного контрпримера. Не, я в принципе не собираюсь столько на клаве печатать в шелле. А когда там еще и автодополнение такое как там, пути с пробелами, и брейнфак с типизацией (в шелле!!!) - ну, знаете, вот пусть авторы этого и пользуются им.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:54 , 16-Янв-24 (476) +1
> Какую задачу решает это индусское месиво я не понимаю. > брейнфак с типизацией (в шелле!!!)Ну жирноват-тяжеловат он, но вот идея типизированного шелла должна быть понятна. Должно быть понятно, зачем линуксоиды делают свой powershell в виде nushell.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 03:04 , 16-Янв-24 (479)
> Ну жирноват-тяжеловат он, но вот идея типизированного шелла должна быть понятна. Должно > быть понятно, зачем линуксоиды делают свой powershell в виде nushell.В результате самое крутое что есть в шелле ака мелкая автоматизация системной рутины по месту - здесь и сейчас - там по сути и невозможна. Эффективного интерфейса к системе - нет. Печатать километровые команды и параметры, с почти неработающим автодополнением, а вишенкой на торте еще и пути с пробелами и проч везде (хотели же длинно и интуитивно?) - это здорово, конечно, только в результате я то же самое в лине раз в 5 быстрее делаю. А если еще типизация начнет делать мозг... эээ... ну в общем сделать пайплайн там чаще всего не получается. А если я хотел похардкорить с мощным программизмом - не совсем понятно зачем это в вот именно шелле делать. Оно ж не ide, и с автодополнением джеппа.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 15:53 , 16-Янв-24 (546)
Тебя опять что-ли шиза долбает, 294й? То что по умолчанию идёт с PSReadLine ты оппрыгаешься с башем. Алиасы давно по умолчанию сделаны и выглядят практически как в баш. Если ты в пайплайны не умеешь в ps - иди в дворники. А ещё, для автоматизации быстрой, жду аналог PowerCLI для vmware. Ты же в 5 раз быстрее сделаешь в лине. Покажи примеры.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 19:03 , 19-Янв-24 (649)
> Тебя опять что-ли шиза долбает, 294й? То что по умолчанию идёт с > PSReadLine ты оппрыгаешься с башем.Ну во первых я вобью проблему в поискарь и скопипащу 90% решения. Во вторых я не собираюсь бузинесс-логику или что там еще на шелле бжад наворачивать. Поэтому в 95% случаев мне вон то просто не приболело, а вот минусы - икнутся. > Алиасы давно по умолчанию сделаны и выглядят практически как в баш. А внутрях все равно летающий спагетти монстр с километрами макарон, норовящий типизацией куснуть и чего там еще. И время старта этой байды такое, что у меня в ряди случаев скрипты отработают быстрее чем ЭТО вообще только стартануть расчехлится на VM. Ну я и не понял зачем мне такой шелл надо, не разгоняет мою эффетивность и создает больше проблем чем решает. Не, я не хотел хардкорить в шелле. Для этого другие яп есть. > Если ты в пайплайны не умеешь в ps - иди в дворники. Я пошел в пингвина вместо этого - там с пайплайнами ноу проблем, и вообще, все как-то сильно проще и ненапряжнее. Можно сделать что хотел а не пытаться косплеить лучшие практики мега-иде зачем-то бжаж в шелле, где для этого инструментации нет. > А ещё, для автоматизации быстрой, жду аналог PowerCLI для vmware. Ты же > в 5 раз быстрее сделаешь в лине. Покажи примеры. Ну так я себе ряд операций с виртуалками прекрасно оптимизнул. Конечно для KVM и QEMU, нахрен мне вмварь? Более того - я себе _генерацию_ дебутстрапом наваял - с моими кастомизациями. У вас там уровень сцаного эксплуатанта. А я кастомдев, мне больше надо. На баше я это забацал минут за 10. А на этой повар-щели я бы часами долбался с тем же самым, воюя с не теми типами данных мля, и чем там еще. Оно мне надо?! А, да, ваш коллега пох (или нах?) таки - вот - плакался что вмварь сожрали. Вас ждут интересные времена! И хорошо что все это - не у меня :)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 19:00 , 23-Янв-24 (684)
> Ну во первых я вобью проблему в поискарь и скопипащу 90% решения. У тебя как 294й, с способностью понимать тексты? Проблема? Скопипасть в поискарь и найди что делает PSReadLine, потом рассказывай как в баш это круто. > Во вторых я не собираюсь бузинесс-логику или что там еще на шелле бжад наворачивать. Поэтому в 95% случаев мне вон то просто не приболело, а вот минусы - икнутся. О, опять очередной передерг. Аж два сразу. Во первых бизнес-логика. Про неё тут никто и не говорил. Во вторых примудил мифические минусы. Которые кроме тебя никто не наблюдает. > А внутрях все равно летающий спагетти монстр с километрами макарон, норовящий типизацией куснуть и чего там еще. И время старта этой байды такое, что у меня в ряди случаев скрипты отработают быстрее чем ЭТО вообще только стартануть расчехлится на VM. Это любители башпорятнок рассказывают? Ну те что в соседних треда точно такой же аргумент приводят на тему системд и другой системы инициализации. Только там лапша в баше у них. Ты про алиас то в поисковик можешь вбить болезный? Ну и показать насколько букв команда в баше cd больше цмдлета в пауршеле cd? Хотя у кого хаотическое мышление им действительно не понять - как это правила именования команд сделать и их соблюдать. А поверх сделать просто алиасы. Ну про телегу разных шелов и разное поведение в разных ОС вообще промолчу. Переносимость это не про тебя. Как же ты лохов обувать будешь, если подпиливать твои портянки не надо будет под каждый чих. Проще в несколько команд прогнать объект и вытащить нужный процесс по тому же показателю памяти. Чем писать десятки строк под каждую ОС и шел. Мне своё время дороже. Но твоё ничего не стоит, поэтому пиши партянки с макаронинами под мак-вин-лин и разные шелы. > Я пошел в пингвина вместо этого - там с пайплайнами ноу проблем, и вообще, все как-то сильно проще и ненапряжнее. Ну так все и поняли что ты не умеешь в пайплайны. Сейчас в куче мест ушли все в курьеры. Мест для дворников полно. Сходи - пособеседуйся. Там твоё место. > Ну так я себе ряд операций с виртуалками прекрасно оптимизнул. Опять передерг. Никого тут и в мире не интересуют твоё пердольнье с ардуинками, мелкими виртуалочками и прочим компостом. Нужна "плаформа" для возможности быстро решить задачу. Давай наналог PowerCLI для kvm. Тебя больного с баш-портянками в комплекте к сервису нормальным людям не надо. > Более того - я себе _генерацию_ дебутстрапом наваял - с моими кастомизациями. Да понятно что ты с пердуинками там балуешься, но тут ты этим никого не удивишь. > У вас там уровень сцаного эксплуатанта. Бгыыых. Тебе то виднее у кого что. Гусар-одиночка с пердуинками на шеле пишет письмо сатья-наделле, картина маслом. > А на этой повар-щели я бы часами долбался с тем же самым, воюя с не теми типами данных мля, и чем там еще. Оно мне надо?! Да все уже поняли что ты головка от патефона. Не пробовал это сделать но мнение имеешь. > А, да, ваш коллега пох (или нах?) таки - вот - плакался что вмварь сожрали. Вас ждут интересные времена! И хорошо что все это - не у меня :) Ты не поверишь. powershell от этого никуда не денется. Как и модули к остальным виртуальным средам. Резюмируя. Ни одного ответа на вопрос ты не дал, только попередергивал. Хвост павлиний распушил. Скажи а вот твоё инфоцыганство здесь помогает тебе дуриков находить?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 21:48 , 23-Янв-24 (685)
> Скопипасть в поискарь и найди что делает 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 корпорации мне как-то так себе. А что и куда денется - решаете не вы а менеджмент этой корпы. И я видел как они росчерком пера проекты в утиль - хрясь. > Резюмируя. Ни одного ответа на вопрос ты не дал, только попередергивал. Хвост > павлиний распушил. А я и не собирался играть по вашим правилам. Поздравляю с прозрением. > Скажи а вот твоё инфоцыганство здесь помогает тебе дуриков находить? Оно помогает мне находить единомышленников. Вместе мы надерем ваши задницы по полной программе. Есть такое ощущение.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 06:18 , 24-Янв-24 (690)
Резюмируя два. Инфоцыган 294й забыл сам с чего начал(автодополнения нет, коротких команд нет и т.д.). Определенные решения системы становятся плюсами или минусами в зависимости от того по какие системы сравниваются. Лапша шела vs системд конечно в плюс системд. Лапша шела vs пауршел конечно в плюс шела. Алиасы в шеле vs алиасы пауршела конечно в плюс шела. Короткие ничерта не понятные команды в шеле vs длинные опции в системд конечно плюс системд. Короткие ничерта не понятные команды в шеле vs длинные команды по стандартам в пауршел конечно плюс шела. Ну и дальше портянки художественного свиста. В конце не преминул рассказать про свои латентные потребности. Как же 294й да про орган которым думает не расскажет. Инфоцыган, тебе самому позориться не смешно? Ты же не тянешь в дискуссию. На работу тебя подрядить нельзя - это же по комментам видно что ты за работник.Ты так и не рассказываешь. Что у тебя с повреждениями головного мозга была? Чего скрывать то?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _kp, 22:10 , 16-Янв-24 (586)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 15:23 , 15-Янв-24 (322)
Это объясняется тем, что всё это нужно постоянно набирать. Что касательно rust, то сокращения норм, но не норм | и '. Если с ' ещё как-то можно понять зачем пришлось так сделать, то накой хер взяли | понять уже сложно, ровно как и для чего напичкали ЯП вредными элементами функциональщины. В совокупности падает читабельность кода.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 20:25 , 15-Янв-24 (406) –1
> First of all, Rust uses a different (often, in my opinion, gratuitously so) syntaxИли это значит "мои старческие мозги скатываются в деменцию, новых символов отличных от 'в С/С++' я запомнить не могу; пожалейте старичка"
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 11:14 , 16-Янв-24 (499) +2
Или это значит, что разработчики Раста не смогли осилить нормальный синтаксис, а сейчас уже поздно.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 19:03 , 16-Янв-24 (574)
Это значит лишь то, что Линус, будучи взрослым человеком, способен определить что является его персональным мнением, а что объективной реальностью, о чём и пишет («in my opinion»). Опеннету бы поучиться у него.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Витюшка, 21:59 , 14-Янв-24 (12) +7 [^]
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Витюшка, 22:05 , 14-Янв-24 (15) +2
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:12 , 14-Янв-24 (21) +2
Комьюнити, которое хочет, чтобы кто-то другой на этом языке писал.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., jjklh, 22:28 , 14-Янв-24 (29) +3
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:47 , 14-Янв-24 (67) +2
> Что лучше подходит конкретно для ядра... ОДНОЗНАЧНО zig.Как там у него с портабельностью и вообще готовностью к проду? Вот представьте что завтра билдим кернел им для вашего десктопника. Как, прокатит? Без факапищ?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Витюшка, 01:37 , 15-Янв-24 (101)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 19:03 , 15-Янв-24 (385)
> К сожалению, нет. Я и говорю что некому топить за него. > Топить - не только в рассылках писать "а давайте zig", а именно > допилить до применения в ядре. > Основа там заложена очень крутая.Ну, говоря за себя - если у них референсная реализация на LLVM я лучше тогда хруст поизучаю. Когда в gcc нормально запилят, не раньше. Зависеть на 100% от выходок гугли и эпла как-то не хочется. Тем более что эпл уже начал характерную бадягу с особенным, уличным LLVM в Xcode для себя и вторым сортом - для остальных.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Витюшка, 22:01 , 15-Янв-24 (423) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:47 , 15-Янв-24 (442) –1
> В основном языки имеют одну реализацию. ...гарантирующую 100% вендорлок, что после си и си++ как бы нефиговый регресс, есчо. > С++ в этом плане является прям крайним исключением, просто так сложились обстоятельства. Да, нашлись те кого вендорлоки заколебали. И я вовсе не для того пришел в опенсорс чтобы наслаждаться вендорлоками. Сюрприз! Never again! Так что у меня будет или так - или я поюзаю си и си++, мне хватит. > Как и С. Rust никогда не будет допилен в gcc. Я специально смотрел - пилят > какие-то энтузиасты, один на магистра в универе учится. Это полуальтруисты. Однако вон там уже и borrow checker прорезается. Во всяком случае я вижу какие-то коммиты связанной инфраструктуры. А так Столлман написал первую версию gcc, Торвальдс накатал в 1 лицо Linux, упрямец Кент cow файлуху своротил. Большие вещи начинаются с малого. > Базовых вещей не умеет. Для ядра это наверное не будет пригодно никогда > (в обозримом будущем). Но пропихнуть Rust в kernel это не помешало 😄 Ну он так пропихан что пока на него ничего реально не завязано. И кмк решение будет ли на него что-то завязано более плотно - ощутимо зависит от того будет ли gccrs юзабельным или нет. Майнтайнеры линуха тертые калачи и влопаться в вендорлок? Ну, эт, Торвальда уже пробовали так лохануть в Bitbaker. И где этот их bitbaker теперь?...
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 03:05 , 15-Янв-24 (135) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 07:45 , 15-Янв-24 (175)
Скорее они насмотрелись на D, а хайп вокруг безопасности заставил оторвать кое-что от стула.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 19:06 , 15-Янв-24 (387) +3
>> У C++ сейчас второе, или даже третье дыхание. По моим личным ощущениям. > Почему? Они насмотрелись на rust и другие языки и начали стандартизовывать нужные > всем вещи?А в rust что-то вообще СТАНДАРТИЗОВАНО?! У него ж ни единой версии стандарта нет. По крайней мере от нормальных standard body. Не, куча хипстеров хаотично корежащих синтаксис под заскоки левой своей пятки и приказ своего корпо-хозяина - это не оно. Вообще совсем. И вот как-то так получается что у хруста нет вообще ни 1 стандарта. В отличие от C++.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Советский инженер, 19:35 , 15-Янв-24 (395)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:50 , 15-Янв-24 (445) +1
> типа на стандартном С можно ядро написать!? Ну, почти. Режим freestanding официально специфицирован с C99 аж. Там правда пары вещей не хватает, это таки вот именно гнутые экстеншны. > вот умора, язык разработан для написания ядер и прочей системщины более 50 > лет назад. имеет нескольео стандартов ,но без гну/ms костылей ядра ОС так и не > собираются. и эти же "стандартизаторы" вещают про стандарты. Потому что в целом код conformant, плюс-минус очень небольшое число мест. А хруст вообще хаотичная помойка, развиваемая абы как. Захотели и перефигачили синтаксис. Наверное так и надо...
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Советский инженер, 11:20 , 16-Янв-24 (500)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 19:17 , 19-Янв-24 (650)
> дооо, язык создавался для симстемщины и ядер ОС, но стандартизировать решили что-то > другое. Отличные стандарты! 🤣Хрустики даже и так не смогли. Все познается в сравнении... которое они и не выдерживают пока, демонстрируя шоу "хаотичная помойка имени питоняш". >>А хруст вообще хаотичная помойка, развиваемая абы как. Захотели и перефигачили синтаксис. > Именно поэтому компиляция ядра клангом периодически отваливается? ведь так? В хрусте системщина вообще в зачаточном состоянии и там вообще не привалилось еще толком - чтобы вообще начать отваливаться. Иногда удается что-то на проволоку и изоленту примотать, чуть ли не с gcc'шным, мля, линкером на страпоне, ибо свой - УГ. Но это видимо не пахнет. Но конечно вы можете скачать ночнушку, высокобезопастным инновационным curl | sh. Там может быть если повезет, уже почти, вот вот, ых, ых, ых... как как грите, фукмсию решили отменить когда как раз почти треть переписали? Ну, во, все правильно сделали. Сразу видно wannabe-успешный проект. Успешно присоединится к Wave, Plus, Picasa и кому там еще в Валхалле. > Это не потому что гнугники что-то постоянно подпиливают в своих нестандартных экстеншонах? > СТАНДАРТ !!! о таком только мечтать! "Но тут снизу постучали" - это были хрустики.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Советский инженер, 11:13 , 20-Янв-24 (660)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 12:17 , 20-Янв-24 (662)
> Хрустики смогли пробиться в ядро, а С++ со всеми своими стандартами не смог.Они пока так пробились что постоянно переделывают свое месиво, постоянно надо самую-самую ночнушку, иначе нихрена не получится, в общем, самый прод. Я допускаю что из этого постепенно может и получится что-то дельное. Но пока это выглядит весьма хаотично, а нужда постоянно тягать начнушки яп намекает на д@рьмовый дизайн где многое не предусмотрели. > Очередной пример, указывающий что стандарты это что-то бесполезное на практике. Ну да, намного лучше, когда кучка хайпующей хипстоты вываливает в синтакс какое-то уг для ублажения сиюминутных хотелок своего вендора. А в результате синтаксис корежат хуже чем у питона, без скачки ночнушки нихрена не работает, и полезные продукты на этом уже прямо захватили мир. Куда там плюсерам до этого, действительно. >>чуть ли не с gcc'шным, мля, линкером на страпоне, > нет никакого gcс'шного, мля, линкера. есть GNU Binutils. Как минимум это все - вообще не заслуга хрустиков. > и тут хрустики тоже поступили практично, как и gcc'шники. Ну вот я подожду gccrs и там подумаю - надо оно мне или нет. LLVMный змейгорыныч мне не приболел, я не фанат ни гугли ни эппла, это те еще кидалы.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Советский инженер, 21:44 , 21-Янв-24 (679)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 21:54 , 23-Янв-24 (686)
> ты как ни плюйся желчью, а факт есть факт. раст в ядре. а плюсы нет.В ядре много чего было. И не все из этого с нами сейчас. Так что это само по себе еще ничего не означает. С другой стороны - может из этого и выйдет что-то дельное постепенно. Но пардон, качать ночнушки компилера - не стандарт а хипста-треш. >>Куда там плюсерам до этого, действительно. > точно не в ядро. Они чем-то принципиально хуже хрустиков? > это как раз показывает что хрустики практичные. Если бы они были бы практиными, потратили бы немного больше времени на архитектуру и изучение чужих фэйлов, тогда не приходилось бы перекачивать постоянно компилер и корежить синтаксис. Но с этим кажется облом вышел. > и да, это так же не заслуга приплюснутых. А бинутилсам плюсы юзать не разрешили случайно? В гцц - точно можно. >>Ну вот я подожду gccrs и там подумаю > ага, держи нас в курсе. всем очень интересно (нет). Да вы и кернел линуха врядли трогаете даже трехметровой палкой, так что...
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:06 , 14-Янв-24 (17)
>Эх, жаль некому также топить за Zig (и он недостаточно стабильный для ядра).Возможно потому что его компилятор работает только на последних версиях систем?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Витюшка, 22:15 , 14-Янв-24 (23)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:50 , 14-Янв-24 (41) +2
Вот только для ядра будет требование сборки с использованием gcc. Для раста из-за этого начали делать gccrs, было утверждено добавление GCC 13 (https://www.opennet.me/opennews/art.shtml?num=57491) в виде беты и так далее. А что у Зига? Разве есть хоть какие-то подвижки?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:48 , 14-Янв-24 (68) +1
> Там llvm. Всё что поддерживает llvm в целом должен или может поддерживать Zig.Тогда EPIC FAIL - он получает тот же отлуп что и хруст в сравнимой дискуссии в git, ибо LLVM не особо то кроссплатформенная штука и далеко не все архитектуры поддерживает. Здорово сливая GCC по поддержке железа.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 00:03 , 15-Янв-24 (76) –5 [V]
У LLVM все прекрасно с поддержкой платформ. Это GCC поддерживает всяких хлам и некроплатформы
- Дискуссия об использовании языка C++ для разработки ядра Lin..., jjklh, 03:38 , 15-Янв-24 (145)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 10:53 , 15-Янв-24 (226) –2
> ну, ладно выкинут поддержку неподдерживаемых платформ из ядраПри чем тут все платформы? Зачем тебе новейший драйвер напр. сетевухи на 100Гб на PDP-11 или System/370? Сильно убудет если он не будет там поддерживаться, если он не компилится из-за шланга? Шланг даже m68k тяшет. Приведи пожалуйста пример, отсутствие какой архитектуры - блокер. > Оно ж тупо не собирает ядро трехлетней давности А ты обратил внимание, что андроиды собираются все, кроме android15‑6.6 старыми шлангами? Не задумался почему так? Может просто гугл следит за этим и исправляет в ядре/шланге что нужно? Вот если и в ядре будут следить, то компилится будет. Или ты думаешь что gcc просто самом собой начинает поддерживать все без проблем?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 19:12 , 15-Янв-24 (390)
> У LLVM все прекрасно с поддержкой платформ. > Это GCC поддерживает всяких хлам и некроплатформы BSDшники уже пробовали рассказывать сказку про (не)нужные всем фичи. И где они теперь? Вот и вы туда же с этим всем отправитесь. По тем же причинам. Мне вот например не нужны тулчейны где так внаглую лечат что мне (не)нужно. Я и не буду такими тулчейнами пользоваться.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 04:29 , 17-Янв-24 (602)
Да нет там никакой битвы, тем более легендарной. Очень вялая дискуссия где одни челы говорят, что Раст всё равно лучше, а другие челы обсуждают все причины, по которым С++ впилить в кернел не получится, во всяком случае что бы с++ при этом оставался полезным.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:04 , 14-Янв-24 (13) +6 [^]
Линус сам прекрасно осознаёт, что из-за своего ЧСВ и ощущения хозяйскости наговорил глупостей. Но из-за такого китайского концепта как "потеря лица" он не может признать, что говорил глупости.Разумеется, ядро давно необходимо перевести на C++ хотя-бы из-за его AST-безопасных inline-функций, улучшенной проверки типов в вызовах функций и compile-time вычислений (да, я знаю, они тяжёлые. Но в C++ есть модули, в них такие вычисления закешируются). Но необходимо ввести жёсткую конвенцию по написанию кода о том, что должно линковаться на уровне хэдеров, что - статически, а что - динамически, и разработать линтер. Без линтера тут никуда. За header-only нужно сразу от разработки отлучать с волчьим билетом.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 00:09 , 15-Янв-24 (79) +1
Линус может сказать, что уже прошло много времени и язык существенно изменился в лучшую сторону, и всё. Ты как тогда не хотел понимать какие претензии были к с++, так сейчас не будешь разбираться что же изменилось в лучшую сторону.> Разумеется, ядро давно необходимо перевести на C++ хотя-бы из-за... Кроме из-за ещё есть и аргументы против. Твоё выдёгивание только из-за' ничего не стоит
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 00:53 , 15-Янв-24 (94) –2
>Линус может сказать, что уже прошло много времени и язык существенно изменился в лучшую сторону, и всё.Он высказался не о языке. Он не подумав (зачем ему думать, он же диктатор-хозяин-барин и ядро - его собственность! правда потом спонсоры ему пояснили, who is who.) ляпнул, что недопуск C++ в ядро - это мера по недопуску в ядро программистов N-го сорта - программистов на C++. Если теперь он допустит в ядро программистов на C++, то ему придётся признавать 3 вещи: 1. что программисты на C++ - это не программисты N-го сорта 2. что Линус необоснованно из личной гордыни задел достоинство программистов на C++ 3. что оттолкнув по мотивам личной гордыни и неприязни определённую группу программистов Линус проявил непрофессионализм и замедлил развитие проекта
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:14 , 15-Янв-24 (110)
Не знаю о каком именно высказывании говоришь, я видел только где в основном обсуждался ЯП
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 15:11 , 15-Янв-24 (318)
> то ему придётся признавать 3 вещи:- что теперь программисты N-го сорта допущены в ядро.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:33 , 15-Янв-24 (368)
Тут у Линуса осталось 3 варианта действий: 1. покаяться за вред, нанесённый проекту, и извиниться перед крестовиками. Будет больно и неприятно, но возможно тогда его оставят. Возможно... Не значит, что гарантированно. Тут главное - грамотно обосновать, почему смена руководства нанесёт проекту больше вреда, чем пользы. Если обоснует - то останется. Но лицо потеряет. 2. играть в несознанку и дожидаться, пока всех доставшего эгоиста прирудительно не снимут. 3. одобрить включение C++ в проект и попытаться замять историю с балабольством. Не выйдет - история широко известная, тут же найдутся те, кто включит аргумент "раз программисты на C++ плохие, то зачем ты их в ядро допустил, лидер ты наш Акелла? если они вдруг стали хорошими, хотя мы все знаем, что с обыдлением всё становится хуже, то как же так получилось, что твои слова противоречат реальности, может ты просто не хочешь признавать свою ответствееность за свой базар и свои действия? Зачем нам такой лидер?"Линус загнал себя в цугцванг сам своим безответственным поведением. На мой взгляд ему наиболее выгодно идти по пути 1. Но это сторонний взгляд, что в башке у Линуса - никто не знает.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 20:38 , 15-Янв-24 (410)
Лол, а почему он не может сказать "раст уже в ядро добавили, зачем там третий язык?" Более того, а за что каяться? От добавления С++ ядро лучше бы не стало, по аналогии с Сишкой С89 сидели бы на С++98 до 2022 года( Так что никаких смартпойнтеров и прочих даров цивилизации.Более того подозревая, что дудуки пилящие ядро начали бы писать в стиле "как умеют". ИМХО тогда стало бы еще хуже.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _kp, 22:32 , 16-Янв-24 (587)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Синий попугай, 00:18 , 15-Янв-24 (86) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 01:21 , 15-Янв-24 (97)
>Что именно подразумевает 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++ для разработки ядра Lin..., n00by, 06:45 , 15-Янв-24 (164)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 12:56 , 15-Янв-24 (267)
>> и в каждый бинарь включена своя копия реализации. > Подтверждением в виде дизассемблерного листинга не порадуете?Не тормози, сникерсни! Если либа в .c/.cpp и ее отдельным .so сделали - все три проги поюзают один shared lib, если либу так собрать. Будет реюз кода либы. А если это все было в header-only - опа, хидер .so не сделаешь! И все три получат свои приватные реализации фич которые они оттуда использовали и реюз кода не состоится. Это и есть обратная сторона header only. И интересно, чем тут дизассемблер поможет? Бывают конечно еще псевдолибы где кроме препроцессора и определений нихрена нет, но он видимо про полновесные хидеры с кодом.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:12 , 15-Янв-24 (360)
А если у вас библиотека шаблонов, то методы с шаблонными параметрами тоже приходется в заголовочниках.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., n00by, 14:22 , 16-Янв-24 (523)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 12:25 , 20-Янв-24 (663)
> Тормозят пока что эксперты и внедрители Си++ в Linux. У меня стандартная > библиотека для ядра header-only была 15 лет назад.И это все круто и офигенно - потому что что? С чисто практической точки зрения, если вы завтра перестанете существовать, вместе со своей либой - для меня изменится ну вот например что? Ах, ничего? Тогда и смысла передо мной рисоваться со всем этим - примерно ноль. Набивайте себе цену перед теми кому ваши поделия полезны, имхо. Это не я.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 07:32 , 16-Янв-24 (486) +1
>Если всё линкуется в один бинарник, то вообще может быть ошибка линковкичудик не знал про #pragma once, но уже требует кого-то там вон из профессии :)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:13 , 16-Янв-24 (589)
Э... Очевидно имелось ввиду именно линковка.Один файл компилируется в объектник с включенным заголовочником. Другой файл генерируется объектник с включенным заголовочником. Оба содержат одинаковые сгенерированные функции. Теперь линкуем это в один бинарь и получаем ожидаемый нежданчик.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 03:03 , 15-Янв-24 (132) +4
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 03:04 , 15-Янв-24 (133)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 09:44 , 15-Янв-24 (194) –1
Давно есть. Человек просто поумничать хотел
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 11:20 , 15-Янв-24 (238) +1
C с этими добавлениями называется C++ :).
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 14:16 , 15-Янв-24 (298)
Похожими вопросами многие задавались ещё лет 15 назад, однако время прошло и Си как был бревном, так им и остался. С другой стороны, плюсы постепенно движутся куда нужно, но медленно. Скорее уж в плюсах появится ABI, чем в Си занесут новые фичи
- Дискуссия об использовании языка C++ для разработки ядра Lin..., fuggy, 04:44 , 15-Янв-24 (150) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 05:13 , 15-Янв-24 (155) –1
На rust переписывать не придётся. Его засунули в ядро чтобы шумные детишки наигрались молча с какой и потом остали от ядра сами
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 07:41 , 15-Янв-24 (173)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 12:38 , 15-Янв-24 (253)
Раст - навсегда в ядре. Учитывая, сколько уве в сетевых подсистемах ведра на сишке, раст безалтернативен. А вот всякие алгоритмы сморт пойнтерс в плюсах далеко не каждый будет подключать, ибо плюсы и так громоздкие.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 14:28 , 15-Янв-24 (302) +1
Ничего нигде не бывает навсегда, ты сам тут не навсегда. Как засунули, так и уберут. Тем более если говорить о языке в ядре, на котором пока что ничего важного нет кроме hello world. И если оно уже на Си и хорошо работает, значит вполне себе альтернативы есть - тот же Си. Учись рассуждать у мастера логики.> А вот всякие алгоритмы сморт пойнтерс в плюсах далеко не каждый будет подключать, ибо плюсы и так громоздкие. Несёшь какую-то чушь, но можно поговорить об интеграции. Как уже заметили в обсуждении, c++ проще интегрируется в существующий код - точнее, интегируется, а rust - нет. У rust в лучшем случае какое-то время будет ниша штучных драйверов. Если рядом с rust появятся плюсы, то большинство разработчиков просто пойдёт по пути наименьшего сопротивления и выберет c++. А объяснить зачем нужно менять правильно приготовленные плюсы на rust уже намного сложнее.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 14:51 , 15-Янв-24 (310)
Дело в том, что решают корпорации, они пишут ядро за свои деньги, и они выбрали раст. Платиновым спонсорам нужен раст, а плюсы им не нужны. Вот так вот...
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 15:28 , 15-Янв-24 (323)
Когда какой-нибудь Google начнёт массово релизить либы и продукты на rust вместо С++ и Go, тогда можно будет считать что выбрали. Пока что это местячковые потуги, как и со всеми остальными модными технологиями. И опять таки, ничего не бывает навсегда, особенно у корпораций: у них бабла много и не жалко выкинуть игрушку на помойку в любой момент
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:18 , 15-Янв-24 (362) +1
>Учитывая, сколько уве в сетевых подсистемах ведра на сишке, раст безалтернативен.А сколько на сегодня Раста в сетевой подсистеме ядра? Помоему, пока что хрен целых, хрен десятых.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 17:20 , 15-Янв-24 (351) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:11 , 14-Янв-24 (19) +1
>В качестве минимальной упоминается использование спецификации C++14Не, нужно сразу 26 в редакции clangа на сегодняшний день брать. Потому что без ranges делать compile-time вычисления невесело. Хоть в шланге и нет ещё полноценных ranges, уже то что есть - очень полезно и убирает кучу того, что либо вручную приходилось держать в актуальном состоянии или скриптом генерировать (напр. индекс максимального элемента массива из фиксированных compile-time значений). magic_enum вообще офигенно полезная либа. Она хоть и header-only, но она не приводит к оверхеду на каждый включённый экземпляр, как если бы nlohmann json включили в один модуль, а потом во второй, и всё header-only. Другая офигенна полезная либа - это ctre.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 09:49 , 15-Янв-24 (195) –1
вот честно... чем пользоваться этой синтаксической ахинеей проще написать в 5 строк скрипт на том же питоне для предвычислений
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 13:25 , 15-Янв-24 (279)
И огрести на ровном месте проблем, в частности тащить 2 реализации одного и того же на разных языках и гемороиться с интеграцией питоньего скрипта в систему сборки, чтобы каждый раз не пересобирало? Не, спасибо, я лучше ranges поюзаю.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 14:47 , 15-Янв-24 (309) +1
> И огрести на ровном месте проблем, в частности тащить 2 реализации одного > и того же на разных языках и гемороиться с интеграцией питоньего > скрипта в систему сборки, чтобы каждый раз не пересобирало? Не, спасибо, > я лучше ranges поюзаю.А потом через полгода выйдет новый пихон - и вообще сборочница сломается. Питонженетормозит и у него отличная совместимость между версиями. Вам что, впадлу чтоли код подправить? Да, блин, знаете, когда начинает сыпаться с 9000 разных сторон - таки, впадлу!
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 17:58 , 15-Янв-24 (357)
В пакетах всё ещё можно поставить второй питон. Так что да, ничего не сломается. Конечно, для задач выше он не нужен, а именно - любая кодогенерация зло.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 19:27 , 15-Янв-24 (394)
> В пакетах всё ещё можно поставить второй питон.Это в каких бы таких пакетах? Поддержку питона2 вынесли сами питоняши еще сколько там назад. Линуксные дистры и вынесли его - они быть святее папы римского не собираются, майнтайня софт за питоняш. > Так что да, ничего не сломается. Конечно, для задач выше он не нужен, а именно > - любая кодогенерация зло. Оно и видно что там не сломается. В дебиане 12 было аж 3000 чтоли багов на эту тему. Всего-то, блин. Они и задропали половину софта к хренам, им что, больше всех надо?!
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:04 , 15-Янв-24 (424)
Итерация свойственна человеку, кодогенерация божественна.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 13:45 , 15-Янв-24 (289)
Засуньте ваш Шланг в... Ядрописатели требуют обязательность сборки GCC.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:39 , 15-Янв-24 (371) +1
Шланг отстаёт от gcc по фичам языка, но опережает по строгости, статическому анализу, удобству использования и скорости результирующего кода. Тех же концептов до сих пор нет, и это создаёт проблемы для кода, который написан под gcc. Если шлангоспецифичные расширения не юзать - то gcc соберёт то, что собирается шлангом. Поэтому ориентироваться надо именно на собираемость шлангом.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Placeholder, 22:14 , 14-Янв-24 (22) +9 [^]
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:25 , 14-Янв-24 (26) +1
Так и си этого не гарантирует как и большинство высокоуровневых языков с >1 компиляторов.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Bottle, 22:28 , 14-Янв-24 (28)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:34 , 14-Янв-24 (31)
В ядре тоже нету VLA. В стандаре C99 было, но потом, поняв ошибку, сделали это в следующем стандарте опциональным.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:38 , 14-Янв-24 (58)
А в чём проблема VLA? Лучше с alloca и указателями для того же самого геморроиться и статическому анализатору палки в колёса ставить?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:54 , 14-Янв-24 (70) +1
> А в чём проблема VLA? Лучше с alloca и указателями для того же самого > геморроиться и статическому анализатору палки в колёса ставить?В том что... 1) Никогда не знаешь когда этот код навернется. 2) Способов узнать навернется ли он - нет. 3) В стандартах "C" нет слова "стэк" от слова вообще. 4) Поэтому вы в душе не и...те сколько его доступно и плохо ли arr[n] или прокатит. А теперь представьте что у вас по рандому будет грохаться ЯДРО по причине "переполнение стека". Как вам такая перспектива? Этот аспект конечно существует всегда но с именно VLA он вылезает наиболее зло и часто. Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000. При том вы даже узнать не можете ок ли такой n или нет. В отличие от мануальной аллокации где хотя-бы зввернут. А тут - сразу SIGSEGV какой бу, или что там. Круто, да?!
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 01:30 , 15-Янв-24 (99) –1
От переполнения стэка ни один код не защищён. И ни один код не защищён от исчерпания памяти. > Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000. При таком n, даже если всё в куче будет, на большинстве компов грохнется. И всё тут. И там и там надо ограничивать разрешённые значения N.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:08 , 15-Янв-24 (106) –1
Всего лишь 100Мб, не грохнется. Тем более запрос через аллокатор никогда не приведёт к сваливаю
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:51 , 15-Янв-24 (126)
Тьфу, действительно мегабайт, перепутал с гигами.>Тем более запрос через аллокатор никогда не приведёт к сваливаю С выделением на стеке тоже можно проверять, не случится ли переполнения. Но built-inа для этого в компиляторах нет.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 14:10 , 15-Янв-24 (297)
> Всего лишь 100Мб, не грохнется. 1) Ну попробуй так на AtMega какой-нибудь :). Правда, грохаться этот убогий не умеет чисто технически, ибо хардварных exceptions у авр нет как класса - но каким-нибудь интересным глюком в корчах в его фирмваре наверное воздастся. 2) Даже если это ОС - а ты уверен что сто мегов в вот именно стеке процесса таки дадут? > Тем более запрос через аллокатор никогда не приведёт к сваливаю Это не обязан быть запрос через аллокатор... одна из причин по которым операции на стеке быстрее операций в heap. Фича стека в том что он аллоцируется и деаллоцируется автоматически, чаще всего с нехилым подпором железом. Антифича состоит в том что вы не можете узнать прокатило это или нет иначе как fault handler'ом "все пропало шеф!" в тыкву (или жесткими глюками если оно так не умело).
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 15:34 , 15-Янв-24 (326) –1
Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти? Речь про кучу, если вдруг проблемы с чтением> Фича стека в том что он аллоцируется и деаллоцируется автоматически, чаще всего с нехилым подпором железом. Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны железа самая топорная
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 20:23 , 15-Янв-24 (405)
> Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти?А ты думал, штуки типа SIGSEGV из воздуха чтоли материализуется? А вот и хрен, это проц аппаратное исключение кинул на самом деле. > Речь про кучу, если вдруг проблемы с чтением В ней в конечном итоге тоже - память либо выделят, либо при левых поползновениях SIGSEGV будет. На самом деле в линухе при оверкоммите (т.е. по дефолту) это не сильно лучше стека ибо де факто аллокация "виртуальная" и ничем не обеспечена. Реальное выделение только при обращении. Связано с тем что многие программы заказывают намного больше памяти чем реально юзают, и это позволяет на доступном RAM нафоркать сильно больше процессов, соответственно. Ценой некоей утратой предсказуемости - ибо ежели страница понадобилась - но ее нет - у вас *alloc вроде прокатил но это как бы и не обеспечено и нате-ка вам SIGSEGV. Но на внутренности кернела это не распостраняется. > Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны > железа самая топорная У heap и такой нет - поэтому аллокации и деаллокации многократно тормознее.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:45 , 15-Янв-24 (426)
> Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти?А ты думал, штуки типа SIGSEGV из воздуха чтоли материализуется? А вот и хрен, это проц аппаратное исключение кинул на самом деле. > Речь про кучу, если вдруг проблемы с чтением В ней в конечном итоге тоже - память либо выделят, либо при левых поползновениях SIGSEGV будет. На самом деле в линухе при оверкоммите (т.е. по дефолту) это не сильно лучше стека ибо де факто аллокация "виртуальная" и ничем не обеспечена. Реальное выделение только при обращении. Связано с тем что многие программы заказывают намного больше памяти чем реально юзают, и это позволяет на доступном RAM нафоркать сильно больше процессов, соответственно. Ценой некоей утратой предсказуемости - ибо ежели страница понадобилась - но ее нет - у вас *alloc вроде прокатил но это как бы и не обеспечено и нате-ка вам SIGSEGV. Но на внутренности кернела это не распостраняется. > Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны > железа самая топорная У heap и такой нет - поэтому аллокации и деаллокации многократно тормознее.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., n00by, 15:00 , 16-Янв-24 (533)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:49 , 15-Янв-24 (124) +2
> От переполнения стэка ни один код не защищён. И ни один код > не защищён от исчерпания памяти.Если я статически пишу 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. Просто крах без предупреждения, в рантайме, без возможности это обработать - может и ок для питоняш, но в системном яп - такое себе.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., jjklh, 03:25 , 15-Янв-24 (138) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 03:28 , 15-Янв-24 (139) –2
>Просто крах без предупреждения, в рантайме, без возможности это обработать - может и ок для питоняш, но в системном яп - такое себе.Сишечка не системная - также можно исчерпать стек, вызывая функции. Особенно если где-то там, в глубине вызовов, будет на стеке буфер, не VLA, но и не очень маленький - есть вероятность, что почти всегда из него будет использоваться пару байт, а иногда столько, что хватит для переполнения стека. VLA, конечно, усугубляет, но сишечка сама по себе неадекватна задачам сиспрога например.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 13:29 , 15-Янв-24 (283) +1
> Сишечка не системная - Да? А кто у нас тогда системный то? На сях что-то большая часть системщины, бутлоадеры, кернелы, фирмвари, либы, вот это все :). И у других - failure mode еще больше так то. В сях они простые и понятные как правило и их немного. > также можно исчерпать стек, вызывая функции. Особенно если > где-то там, в глубине вызовов, будет на стеке буфер, не VLA, > но и не очень маленький - Одна из причин по которым жирное использование стека в функциях считается чем-то нехорошим, и кернел собирается с варнингом на размер стекфрейма, если что. По моему если у функции стек более кило - нате вам варнинг, во! Кстати с современным компилером допустим сожрать стек рекурсией не так то просто, gcc допирает убрать сохранение-восстановление, копирование объекта и проч - и лианеризует рекурсивный вызов до чего-то типа цикла, с потреблением стека O(1) и временем выполнения O(n). И вот я вкатил рекурсию чтобы проверить работает ли мой детект stack overflow на мк и.. это не падает?! Ах ты ж блин, какой умный компилер! А чо, ассемблерщики, сможете оптимизнуть так же? :) > есть вероятность, что почти всегда из него будет использоваться пару байт, а иногда > столько, что хватит для переполнения стека. Поэтому... 1) Там где это важно чекают stack usage функций. 2) MISRA запрещает рекурсивные вызовы например, и системный софт должен намотать на ус эту идею и так не делать. > VLA, конечно, усугубляет, но сишечка сама по себе неадекватна задачам сиспрога например. Ну вы то нам покажете что-то лучше? А то уж рекурсию можно на чем угодно, даже на асме, и тот кстати без оптимизаций - не будет линеаризовывать рекурсивный вызов до более плоского цикла и там все грохнется куда охотнее :)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 03:29 , 15-Янв-24 (140) +1
В некоторых компиляторах есть builtin, позволяющий проверить наличие места на стеке. Где нет - его можно сделать. По-хорошему должен быть вариант alloca с проверкой. Но нет. По-хорошему должен быть VLA с проверкой на успех. Но Си - это не раст.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 13:50 , 15-Янв-24 (292) +1
> В некоторых компиляторах есть builtin, позволяющий проверить наличие места на стеке. Где > нет - его можно сделать. По-хорошему должен быть вариант alloca с > проверкой. Но нет. По-хорошему должен быть VLA с проверкой на успех.Просто вопрос был почему VLA не рекомендуют в системщине. Ну вот потому. В сях вообще нет ни слова про "stack" в спеках. И, в принципе, VLA не обязан жить именно в стеке. Однако проблема того что память не бесконечная а какая-то реакция на ее нехватку невозможна - остается в любом случае. > Но Си - это не раст. Что-то мне подсказывает что у хруста других failure modes - на десяток си хватит. Они вон там свой panic любимый едва законопатили, меняя чуть не сорц компилера аж когда оказалось что в ядре panic это не оч хороший способ реакции на нехватку памяти. Там же и сказочные костыли с try-вариантами конструкций. Господи, какой бастардизированый гибрид сей с которыми боролись и чего-от из плюсоты, все хучшее от обоих миров - в один яп?!
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:48 , 15-Янв-24 (375)
>VLA не обязан жить именно в стекеЛокальные переменные живут в стеке. VLA в принципе может жить где угодно, но нужен он именно на стеке. >Они вон там свой panic любимый едва законопатили panic!ует код тогда, когда не обработана ошибка, в частности наиболее распространённый случай - когда на std::result вызывают unwrap. В системном кодe необработанных ошибок быть не должно - это путь либо к уязвимости, либо к kernel panic. rust это просто подсвечивает.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:02 , 15-Янв-24 (429)
> Локальные переменные живут в стеке. VLA в принципе может жить где угодно, > но нужен он именно на стеке.Читайте стандарты си. Там вообще нет упоминания стека, никак и нигде. То что конкретные реализации решили делать так - ну, окей, однако если кто-то сделает это иначе, он - в своем праве. Это implementation defined хрень. Вы не можете уповать на это при написании программы. Поэтому если кто-то вывесит VLA через heap или что там у него - а они в своем праве были. У си довольно интересные стандарты - и далеко не всегда это именно похвала комитету. Спихнувшему более 9000 своих проблем на других. >>Они вон там свой panic любимый едва законопатили > panic!ует код тогда, когда не обработана ошибка, Я так понимаю что паника была дефолтовой реакцией на неуспешные потуги аллокации крупных массивообразных штук, box чтоли, они там называются. И дошли они в результате до костылирования с тем же названием с довеском try отличающим по поведению эту сущность. Я честно говоря не понял почему все так костыльно и почему они так героически заборов дракона вдруг заметили что без него что-то стало хреново - и немедленно превратились в еще более стремного на вид дракона. Пппростите, а чем ЭТО отличалось от *alloc и сотоварищи? Можне мне этот высококонцептуальный пируэт объяснить? В результате маркетинг оказался, как бы это, не совсем правдой. Ибо в итоге пришли к тому с чем боролись. Фэспалм. > в частности наиболее распространённый случай - когда на std::result вызывают unwrap. А в кернеле и вообще embedded, etc вот именно тот std вообще будет? Ибо врядли дефолтовый, из супер-дупер-либы на все оказии делает именно то что уместно делать в недрах кернела. И скорее всего подразумевает работу в нормальной ос. А что если этой нормальной ос еще нет?! > В системном кодe необработанных ошибок быть не должно - это путь либо к уязвимости, > либо к kernel panic. rust это просто подсвечивает. И я не понимаю почему в wannabe-системном яп потребовались вон те костылищи с отдельными сущностями. Появившимися вот именно после потуг в кернел влезть. И там аж компилер постоянно патчат под это все. Представьте себе что для написания кернела требовалось бы постоянно патчить GCC. Вы бы вообще смогли кернел написать в результате? Да и Торвальдс, пожалуй, тоже.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 03:41 , 15-Янв-24 (146)
>Если я статически пишу uint8_t arr[10]; я имею основания полагать что это будет работать даже на микроконтроллере с склерозом вместо памяти, и если этот код вообще запустился то скорее всего работает до упора.Конечно, не будет. Во всех тестах в массив будут записаны 1-3 байта и они ничего не поймают, в продакшоне наконец-то в этот массив запишут из сети 10 байт, запись затрет канарейки и структуры планировщика FreeRTOS, лежащие прямо за концом стека, задача вместо паники зависнет и девайс ребутнется по ватчдогу.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 13:45 , 15-Янв-24 (290)
> Конечно, не будет. Во всех тестах в массив будут записаны 1-3 байта > и они ничего не поймают, в продакшоне наконец-то в этот массив > запишут из сети 10 байт, запись затрет канарейки и структуры планировщика > FreeRTOS, лежащие прямо за концом стека, задача вместо паники зависнет и > девайс ребутнется по ватчдогу.Это всякие системные ламеры, обложивщиеся RTOS не поймают, у них "тойота" и получается. А я посмотрел на тойоту. Подумал. И теперь - даже на Cortex-M без MPU научился делать лэйаут RAM где переполнение стека хоть на байт немедленно эскалирует в HARD FAULT (нет, не MPU, его нет), который не заметить очень сложно. Ибо самый суровый эксепшн на все ядро, выбивающий все кроме NMI нафиг. И теперь мы займемся реакцией на вот это, зная что в системе Ж, ждать вачдог не обязательно. ...а еще я таки сделал обработчикам приватный стек, так что они еще и что-то сделать могут. Даже если основной стек кончился. У ARM для этого довольно клевая фича есть, отдельный стек для handlers. ...кроме того я заинструментил немного наколенный, но весьма забавный анализ worst-case рантайм потребления стека. Идея проста: заполняем раму паттерном в startup, пускаем фирмвару работать, если знаем самые ресурсоемкие ветки, прозваниваем их. Через некоторое время просим дамп оперативы, смотрим на регион стека, делаем выводы о runtime margins.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Tron is Whistling, 16:42 , 15-Янв-24 (345)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., nothingaboutdog, 20:45 , 15-Янв-24 (413)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:08 , 15-Янв-24 (431)
> Главное, чтобы у тебя этот суровый(r) эксепшн(tm) не произошёл во время полёта > на обоих модулях - основном и запасном...Если это важно - это решается другими методами. См. как это кажется, боинг сделал. Две тимы писали 2 разные программы, запущенные на 2 разных процах, ... вот как раз чтобы вероятность этого была ниже плинтуса. ...у меня, к счастью, не настолько крутые требования, и все же мне охота залезть в довольно требовательные применения, где факап управления может чего-нибудь пожечь и проч, что как бы не прикольно. В этом смысле fail fast с приведением системы в безоапсное состояние лучше чем ждать вачдога в абы каком состоянии, делая хзчто.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Tron is Whistling, 11:27 , 16-Янв-24 (503)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Tron is Whistling, 11:28 , 16-Янв-24 (504)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 20:56 , 21-Янв-24 (677)
> Мне у некоторых софтсвитчей вот этот fail fast нравится. > Да пусть оно лучше сессию дропнет, наплюёт херни в логи, или выдаст > в сессию шум океанов марса. > Нежели все 100500 звонков разом лягут.Софт свич несколько отличается от печатки с силовухой, допустим. Одно дело по превышению тока сразу в safe state свалить, и совсем другое - подождать вачдога, который там дескать может ребутнет, но до того момента - силовые ключи - и половина платы - правратятся в чуть ли не кусок плазмы уже, и тогда х... толку с вачдога?! Даже если проц и перезагрузится - то чего? В этот момнет уже поздняк на превышение тока реагировать и что-то выключать.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Tron is Whistling, 22:17 , 21-Янв-24 (680)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:14 , 23-Янв-24 (687)
> Если у вас на плате нет защиты от превышения тока кроме софта По законам Мерфи - устройство порой сгорает первым, защитив предохранитель ;) И FYI, предохранитель нельзя брать впритык - иначе периодически его будет выбивать "без причины". А еще пусковые кратковременные режимы бывают куда тяжелее крейсерских. Это не значит что они вдолгую безопасны. Работает этот мир так. Но чтобы об этом знать надо немного поинженерить. Так что лишняя линия защиты никому не мешала еще. Алсо вылетевший предохранитель это прерывание сервиса, доволно надолго. Self restart после устранения проблемного условия - лучше чем трах с сменой предохранителя. По причинам выше - быстродействующий предохранитель, "на грани" - не захочется. Ибо придется постоянно заниматься его заменой. А то что медленный обгонит дестрой ключа крутым перегрузом... ну вот не факт. И вот там МК, которому микросекунды дом родной, имеет шансы зарубить проблемное условие ДО того как это станет проблемой. При том он в отличие от глупого предохранителя в курсе, startup это или авария, допустимо ли столько времени, или уже перебор, и так далее. И можно вон те неудачные соотношения несколько обойти. > - я вам очень сочувствую, и да, можно название, чтобы это > не брать никогда? ...сказал тип, стесняющийся уточнить название своего прова за отношение в ipv6 :). Впрочем можете не париться - я масспродом не занимаюсь и ваши шансы купить сие весьма низкие.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Tron is Whistling, 22:16 , 23-Янв-24 (688)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Tron is Whistling, 22:32 , 23-Янв-24 (689)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 17:59 , 15-Янв-24 (358)
Как я понял твои ответы. - Если мы используем массив со статическим временем жизни, то мы надеемся, что стек не переполнится. - Если мы используем обычный массив на стеке, то мы надеемся, что стек не переполнится. - Если мы используем VLA-массив, то много энергично говорим и надеемся, что стек не переполнится.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:21 , 15-Янв-24 (434)
> Как я понял твои ответы. > - Если мы используем массив со статическим временем жизни, то мы надеемся, > что стек не переполнится.И мы можем более адекватно эту идею проверить. Частично даже в компилтайме, смотрением на размер стекфрейма. > - Если мы используем обычный массив на стеке, то мы надеемся, что > стек не переполнится. Это допущение опять же более просто проверить, если нет рекурсии. > - Если мы используем VLA-массив, то много энергично говорим и надеемся, что > стек не переполнится. VLA - это еще хуже чем динамическая аллокация памяти. Потому что это та же динамическая аллокация памяти - но еще и без возможности сделать что-либо осмысленное, и без известного на момент компила upper bound что вообще совсем рубит любой компилтайм анализ этого. Вы вообще не знаете worst case размер стекфрейма этой функции теперь. И таки си - мультипарадигменный. Если ну вот капец как надо - можно сделать "fully static allocation", распределив вообще все статически. Ну то-есть все переменные сделать либо static в функциях, либо глобальными. И тогда - если все выделено сразу на старте, оно не может закончиться вот хоть как. Единственное что остается это глубина вложенных вызовов функций. Это неоптимально по ресурсам - потому что все и вся выделено всегда. Зато гарантии лучше. Вот и выбирайте. Примерно такой же tradeoff существует и в оверкоммите памяти в случае линуха. Можете не оверкомитить и обеспечивать все выделеные адреса физической оперативой. Но тогда сможете намного меньше программ на том же RAM запускать.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 01:39 , 16-Янв-24 (462)
Я почему шучу про "много энергично говорим" - потому что идеи assert'ов для размера VLA, тестирования худшего случая отметаются как немыслимые и тебя куда-то совсем понесло. "Еще хуже чем динамическая аллокация памяти" - вот, фрагментация кучи уже лучше, чем VLA. Даже не "так же плоха", как написала бы MISRA, а хуже.> Это неоптимально по ресурсам - потому что все и вся выделено всегда В принципе на этот случай есть union'ы, но с ними придётся следить не за стеком, а за тем, чтобы не было обращений к неактивным полям и чтобы инициализация активного поля нигде не пропускалась.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 19:38 , 19-Янв-24 (651)
> Я почему шучу про "много энергично говорим" - потому что идеи assert'ов > для размера VLA, тестирования худшего случая отметаются как немыслимыеНе то что немыслимые - а "еще хуже чем динамическая аллокация". Ибо еще менее defined и еще меньше возможностей для корректной реакции. А что должен кернел сделать по assertion failed? В панику брякнуться? Ну, зашибись реакция, конечно. Юзерям понравится. Retry выделения в этой парадигме вообще не получится (смысл повторять тот же assertion?!), вернуть caller'у ошибку - наверное не assert тоже было. И получается как вон то - только еще хуже, ибо грабель больше и контроля над ручкой нет, грабля автоматически подпрыгивает и лупит в лоб всех кто проходит мимо. > и тебя куда-то совсем понесло. "Еще хуже чем динамическая аллокация памяти" - > вот, фрагментация кучи уже лучше, чем VLA. Внезапные крахи и почти полная невозможность их адекватного парирования спускают си до уровня питоняш и нафиг нам такой си вперся вообще? > В принципе на этот случай есть union'ы, но с ними придётся следить > не за стеком, а за тем, чтобы не было обращений к > неактивным полям и чтобы инициализация активного поля нигде не пропускалась. Я даже примерно так (изредка и немного) делаю - но при этом желательно сделать некий interlock ресурса, для проверки использования, иначе так окажется что мы тут храбро юзали массив - а вон там сетапнули DMA, забыли про это, все счастливо пахало... пока DMA не добрался до нас и не протер все к хренам другими данными... а мы не понимаем - откуда, блин, это вообще вот так?!
- Дискуссия об использовании языка C++ для разработки ядра Lin..., n00by, 06:49 , 15-Янв-24 (166) –1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., n00by, 10:54 , 15-Янв-24 (227)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., freehck, 12:30 , 16-Янв-24 (509)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., n00by, 15:13 , 16-Янв-24 (534)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., freehck, 15:27 , 16-Янв-24 (536)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., n00by, 16:10 , 16-Янв-24 (550)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., freehck, 16:27 , 16-Янв-24 (553)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., n00by, 17:45 , 16-Янв-24 (564)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 00:04 , 19-Янв-24 (637)
Размер стека можно задать каким нужно, вызвав соответствующую функцию. Это он по-умолчанию такой, потому что "12 килобайт хватит каждому". А кому не хватит - тот может затребовать больший.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., n00by, 14:58 , 19-Янв-24 (641)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _kp, 12:17 , 15-Янв-24 (251)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 14:00 , 15-Янв-24 (295) +1
>> не защищён от исчерпания памяти. >>> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000. > Хорошо, n=55666, но память процесса переполнена. > Или переполнена иным, более естественным способом.Я знаю что сделает нормальный системщик. 1) Запретит такую конструкцию если без нее можно обойтись. 2) Если нельзя, аллоцирует динамически - и проверит успех. А если неуспех, что-то сделает по этому поводу, от вываливания из программы до retry через некоторое время в надежде что память освободилась (так например некоторые БД делают, вместо того чтобы сразу завернуть, предпринимают несколько попыток, и сдаются только если за энное время не полегчало). > Во встраиваемом ПО можно генерировать прерывания, при попытке выхода за границы области > стека или его части, В обычных программах примерно то же самое известно как какой-нибудь SIGSEGV и в POSIX эта модель по сути и остается. Проц получает исключение от MMU, и кернел в общем то гейтует его программе как сигнал SIGSEGV. Дефолтный хэндлер просто вырубает прогу, но можно и свой прицепить и сделать что-то более продвинутое. Однако если вам приехал fault handler по причине "стек кончился" - ну, э, удачи в корректном возобновлени работы программы. Ведь стека уже не хватило, состояние в "основном потоке" в общем то уже урыто. Корректного гарантированого способа вернуться их хэндлера в основную тушку на этот момент уже не существует в общем случае. > Но и тут, по исчерпании памяти можно только перезапустить ПО, максимум с > частичным сохранением состояния. Окончание стека это весьма грубый системный факап. Ведуший к очень голимым последствиям. Тойота проверяла. Получив class action lawsuit от злющих родственников усопших водил и тех кому острые ощущения от вождения не понравились.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., n00by, 06:48 , 15-Янв-24 (165) –1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:21 , 14-Янв-24 (24) +1
Ну если хруст завозят, то и православные плюсики должны завезти.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Bottle, 22:24 , 14-Янв-24 (25) –9 [V]
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 00:01 , 15-Янв-24 (74)
Модули в рабочем состоянии пока что только в компиляторе от микрософта
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 00:47 , 15-Янв-24 (92) –2
модули - проприетарный рак от майкрософт. хидеры ничего не замедляют, если мозгами хоть иногда пользоваться, что в случае майкрософт невозможно
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 14:26 , 15-Янв-24 (299) +2
header-only библиотеки конечно можно написать так, чтобы они замедляли компиляцию. но так обстоит дело с чем угодно почти. так что просто нужно писать грамотно и ничего замедлятся не будет.такая байка, что компиляция будет очень долгой из-за ho пошла еще со времен кода в духе александреску. ситуация уже давно изменилась а байка осталась.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Ivan7, 22:36 , 14-Янв-24 (33) +3
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:40 , 14-Янв-24 (35) –1
Пусть пихают и раст и зиг и сипипи сразу. И вейланд с системдой тоже сразу в ядро. Ресукликс-Биникс!
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:44 , 14-Янв-24 (37) +2
И Carbon, и VLang - тоже !
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:46 , 14-Янв-24 (39) –1
Не забывая про Zig и Seed (ElenaLang -тоже неплохо )) )
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:52 , 14-Янв-24 (42) +2
> Rust > C++Бедный Linux, как же упорно туда всякую гадость пихают...
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 00:14 , 15-Янв-24 (83) +6 [^]
Если плюсы таки завезут, то rust там быстро сдохнет
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Герман, 08:52 , 15-Янв-24 (184) +6 [^]
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 04:35 , 17-Янв-24 (604) +1
Это тебе так кажется. Раст "пихают" не потому, что "фанаты", а потому, что на то есть объективные причины. Те самые причины, по которым пихают его, а не С++. Это не вопрос того, что кому больше нравится. Это вопрос сугубо технический. И раст чисто по техническим причинам оставляет С++ далеко позади.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 17:06 , 17-Янв-24 (624)
Да, конечно, не потому что 'фанаты'. Давай посмотрим на объективные факты. Основа современного софтверного мира прекрасно существуют вообще на Си, даже не на плюсах. Прекрсно существует несмотря на все проблемы с Си. И rust в этом существовании ничего не может радикально улучшить. А именно не снизит существенно человеко-часы на разработку, ни увеличит кол-во решаемых проблем вообще. Т.е. проблема будущего развития ядра никак не упирается в проблемы Си в ядре.Технические вопросы это можно ли, и как, занести c++/rust в ядро. А нужно ли уже вопрос экономический если рассматривать в объективной плоскости. Оценок, естественно, профита от внедрения никто не делает т.к. это сложно и в реальности вопрос сводится в экспертную плоскость на уровень личных мнений. Если сравнение Си против rust более-менее можно увести в пользу rust, то с псюсами так не получится. Потому что плюсы это сбалансированный ЯП, а rust смещает внимание только на решение одной пробемы и заносит много мусорных решений из функциональщины вроде всё в ЯП выражения вместо высказываний. Выбор rust именно фетиш на единственную фичу и вера в её полезность, тут и близко нет никакого объективного технического выбора. В таком выборе в приниципе нет ничего плохого. Плохое это, будущи гуманитарием, пробовать замаскировать свои предпочтения под некий объективный и технический выбор.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Анонимбус 2000, 22:54 , 14-Янв-24 (43) –1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Антонимусс, 22:55 , 14-Янв-24 (44) +3
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 22:57 , 14-Янв-24 (45)
Хм, я от с/с++ отошел лет так 15 назад. Но вроде наибольшей проблемой в применении плюсов была бинарная несовместимость между разными компиляторами. Тогда как в чистом с можно было линковаться между разными компиляторами, потому что есть бинарная совместимость. Для расширений питона это вроде до сих пор актуально. Не будет ли из-за этого проблем с ядром? Гарантировать что все блобы в ядре и сторонние модули будут скомпилированы одним компилятором никто не может.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:03 , 14-Янв-24 (48)
Ведро беспокоит что-либо, кроме gcc?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:15 , 14-Янв-24 (49)
А разве с СИ не так же? Пришлось делать гну-тые расширения, чтобы собирать ядро.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:33 , 14-Янв-24 (57) +1
>Но вроде наибольшей проблемой в применении плюсов была бинарная несовместимость между разными компиляторами.Я до сих пор проигрываю с того, что они даже схему manglingа стандартизировать не могут.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:56 , 15-Янв-24 (380) +1
Зачем конкретному ядру бинарная совместимость? Эту версию ядра или другую можно полностью с модулями пересобрать другой версией компилятора. Стороннние модули тоже можно пересобрать нужной версией. Про какие блобы речь? Если загружаемые прошивки в девайсы, то пофиг, чем оно там для них собиралось. Оно с кодом ядра линковаться и не будет. Если блободрайверы, так это же хорошо. Мейнтейнеры ядра и так всеми силами борются с блободрайверами. Это им только в помощь. Пусть вендоры приучаются выпускать открытые драйвера.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., 3draven, 22:58 , 14-Янв-24 (46) –3
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:00 , 14-Янв-24 (47) –1
Это не тот самый разраб из Интела, который прислал такой пачт, который даже не скомпилился? И бедяге пришлось выражаться %^!@$%, тк высказаться прямо он уже не может(((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++ для разработки ядра Lin..., Ilya Indigo, 23:22 , 14-Янв-24 (53) –4 [V]
- Дискуссия об использовании языка C++ для разработки ядра Lin..., cheburnator9000, 23:43 , 14-Янв-24 (64)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., anodymus, 23:44 , 14-Янв-24 (65) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., asaaddxasaadd, 00:22 , 15-Янв-24 (87) –1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 02:49 , 15-Янв-24 (123)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., yet another anonymous, 11:19 , 15-Янв-24 (237) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 17:42 , 17-Янв-24 (631)
Ну тут надвое сказано... Что именно "разгребать"?? ООП для того и придумали, что сложность современных систем на порядки выше старых юниксовых пародий. Соотв. без хорошей декомпозиции и абстракций ничего надёжного ты не напишешь.Другой вопрос, что с ЛЮБЫМ ООП языком придётся тянуть и его рантайм (который просто нельзя выкинуть). И как рантайм одного модуля "дружить" с остальными? (включая ядерный) Вот где засада. На одном хелловорлде рантайм прекрасно работает. Но в сложной модульной системе - большой вопрос.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:58 , 14-Янв-24 (73)
> в случае языка С++ можно по частям переводить код с языка C, так как С-код можно компилировать как C++скорее потому, что с++ - надстройка над с > один из ключевых разработчиков ядра в компании Intel того самого intel, который патчи даже не компиляет перед отправкой?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 13:25 , 15-Янв-24 (278) +2
> скорее потому, что с++ - надстройка над сПожалуйста, никогда не пишите код на C++. Вот из-за таких сишников, пищущих на "C с классами" у C++ плохая репутация.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:52 , 15-Янв-24 (378)
Давайте классы на GовноObject делать, так определённо лучше!
- Дискуссия об использовании языка C++ для разработки ядра Lin..., InuYasha, 00:10 , 16-Янв-24 (456)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 10:02 , 16-Янв-24 (491) +1
>> скорее потому, что с++ - надстройка над с > Пожалуйста, никогда не пишите код на C++. Вот из-за таких сишников, пищущих > на "C с классами" у C++ плохая репутация.Не знаю насчёт этого, но от неполной совместимости с C у него репутация портится. Например, type punning через union зачем-то сделали UB. На практике этот приём в плюсах широко используется и если он вдруг где-то сломается, это будет проблемой скорее компиляторописателей, чем пользователей компилятора. Реальный результат изменения - плюсовики бегают и стращают друг друга неопределённым поведением на смех растовикам. Вот сейчас в компиляторах сломать не рискуют, а через 50 лет? То-то же! Но это настолько удобный приём, что UB здесь как первородный грех. Но программирование - не религия, чтобы заниматься догматическим внушением вины перед Комитетом. Может, ему лучше убрать из текста бесполезный де-факто несуществующий UB?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 01:14 , 15-Янв-24 (95) +2
Потом все равно на Carbon переписывать.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 01:18 , 15-Янв-24 (96)
Подскажите, это начало конца или второе рождение?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., bulbasalo, 01:44 , 15-Янв-24 (103)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 11:32 , 15-Янв-24 (245)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 17:38 , 17-Янв-24 (629)
Это конвульсии трупа :) Фактически уже понятно - как только "добрый диктатор" сдохнет, начнётся полный коллапс (не по этой причине, а тупо из-за бестолкового, монолитного, плохо спроектированного ведра). И на каком языке писать ведро вопрос уже стоять даже не будет.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:10 , 15-Янв-24 (108) –8 [V]
Я за ядро на Java. Заколебали уже. Там тоже синтаксис аналогичный. И вообще все есть интернет. У них вон 8-я версия много лет в продакшене и жабомашина может запускать разные версии когда надо. Чего к плюсам привязались? Солянка - так солянка.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:20 , 15-Янв-24 (113) –6 [V]
Пока линуксом управляет один единственный до*боеб, способный забаррикадироваться в своих 80-ых, и единолично принимающий судьбоносные решения, вашему красноглазому сообществу никакой прогресс не грозит. Все вы так и будете сидеть в этом ~1%-ом дер*ме, и извергать желчь в сторону виндовс и прочих маков.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:32 , 15-Янв-24 (117) +2
Что бывает с модными-молодежными компаниями, лезущими поперед батьки в пекло, можно увидеть на примере Мозиллы.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 19:59 , 19-Янв-24 (652)
> Что бывает с модными-молодежными компаниями, лезущими поперед батьки в пекло, можно увидеть > на примере Мозиллы.Есть пример лучще - Fuchsia и ее "вот, мы, ща, на десктопы, столица миоа - в нью-васюки!". Вон там в соседней новости, где гранд-план по захвату мира кажется немного обломался.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:42 , 15-Янв-24 (120) +4
>Все вы так и будете сидеть в этом ~1%-ом дер*ме, и извергать желчь в сторону виндовс и прочих маков. Загвоздка в том, что недолболюбам на маках и виндовс тоже прогресс не грозит, только если прогресс в принятии ректальных зондов в виде ИИ. Ну и при всем ужасе красноглазого ПО аналогов ему не предвидится.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:44 , 15-Янв-24 (372)
> Загвоздка в том, что недолболюбам на маках и виндовс тоже прогресс не > грозит, только если прогресс в принятии ректальных зондов в виде ИИ. Вас услышали! В новом нотпаде уже встроено. Он теперь поди по сети отсылает каждое нажатие клавиши с 100% легитимной отмазкой :). Вы же не могли жить без AI в нотпаде, правда?! :) > Ну и при всем ужасе красноглазого ПО аналогов ему не предвидится. Вон вам чудный новый нотпад от майкрософта. Зато глаза правильного цвета, и стыд их видимо не ест :)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 02:43 , 15-Янв-24 (121)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 03:12 , 15-Янв-24 (136) –2
Че ты несешь? Совет директоров даже если и принимает решения, то не о каждом элементе и в каждой крупной конторе есть жесткая иерархия. Это типо император мать их японии, а это простолюдин. Простолюдин императору нихрена указывать не может потому что лидер может быть только один. Вам дают кость из раста которую разумно можно использовать ради фич типа написания драйверов без ошибок в памяти. То что есть извращенцы которым так проще -хрен с ними. Но каждый червь со своими советами лезущий это не принятие важных решений. То что ты неспособен осилить хоть что-то не значит что кто-то есть твой не так чтобы зашифрованный мат. Черви ничего Линусу не докажут.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 05:05 , 15-Янв-24 (152) +3
Линус понимает как нужно вести такой проект, а ты нет. Сейчас практически весь серверный рынок линуксовый, все другие ~юниксы давно на обочине.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 05:22 , 15-Янв-24 (157)
Один процент на десктопах, а не на серверах. И проблема не в ядре
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 09:00 , 15-Янв-24 (187)
Типичный пример извергания желчи от не линуксоида, обвиняющего в этом других. Ничего нового.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 12:54 , 15-Янв-24 (264)
Форкни ядро и веди его в какое хочешь будущее.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 02:42 , 15-Янв-24 (119) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 02:57 , 15-Янв-24 (128) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 05:07 , 15-Янв-24 (153) +1
Гайдлайны, внезапно, в ядре и для Си есть. Уровень обсуждений далёких от разработки людей.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 14:36 , 15-Янв-24 (306) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 15:35 , 15-Янв-24 (328) +1
Пусть определятся, какие фичи в ядре допустимы. По тем и пишут.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 17:56 , 15-Янв-24 (356) –2
Если на десятичный порядок, то конечно же нет, добавятся пару новых страничек
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 22:35 , 15-Янв-24 (425) +4
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:29 , 15-Янв-24 (436) –2
> Вот дока по стилю С в ядре "Табы это 8 пробелов..." > Вот для примера С++ "Нас не волнует низкоуровневые вещи вроде отступов, а ещё мы предлагаем вам библиотеку." > Qt *Что-то не тянущее на 21 страницу*
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:32 , 15-Янв-24 (437) +1
Мозг вообще пробовал хоть немного подключать, когда писал всю эту чушь?Дока в ядре касается практически только оформления кода (CS), когда как документ от Страуструпа на кучу страниц небольшой учебник по c++ для двигающихся горизонтально. И если даже его нормально распечатаешь, а не как ты через бразуер с гигантским шрифтом, то не будет 700 страниц. 21 страница ядерного CS читается за пару минут потому что там на самом деле не 21 страница, по такой же причине. В гугловом CS много филовского п-жа с рационализайией, его не обязательно читать чтобы понять что от тебя нужно. CS в хроиуме и Qt как раз несколько страничные и, как в случае с ядерным CS, читаются за пару минут. Могу ещё подкинуть данные, например, по Яндексовому CS - тоже 2-3 страницы на 2-3 минуты чтения. Итого, какие выводы... 1. Типичные плюсовые CS на несколько страниц и на максимум 5 минут чтения 2. Объём CS выбирает проект и если тебе удалось найти неадекватов вроде гугла, то из этого не следует, что все CS по плюсам будут такими. Пытаешься натягивать единичный пример на все, когда даже твоя подборка показывает обратное.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:33 , 15-Янв-24 (438)
^ Так и не понял куда приклеился ответ, он был анониму с ссылками
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 23:45 , 15-Янв-24 (441)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:03 , 16-Янв-24 (466)
> Ну ты к Яндексовому стилю не забудь прикрепить гайдлайн по использованию кода из аркадии взамену стд, если он, конечно, есть.Нет гайдлайна, раньше туда тупых не брали. Сейчас пытаешься приклеить документацию по внутреннему устройству проектов к CS по плюсам. Всё же давай начнёшь включать мозг, а? > Помимо CS есть guideline. Я писал именно про guideline, а не про правила расстановки пробелов и скобок. У Страуструпа на кучу страниц развёрнутый guideline, а всё остальное это в основном CS. Ну да, к Qt ещё приклеил документацию до внутреннему дизайну либ, вроде как у них устроены координатные сетки - вот это прямо таки самые настоящие СS и guideline-ы по С++ для Qt. Начни всё же включать мозг, если, конечно, он есть. > У гугла как раз норм описано. Просто другие это не описывают, а потом вынужден на кодревью править "вот это мы не используем", "так мы не делаем"... Чтобы рассказать как "мы (не) делаем" нужно просто рассказать "мы (не) делаем", а не тратить 80% от CS на трёп с размышлениями каким образом гугл докатился до такого CS-а. Ты же на ревью хочешь чтобы клиент просто затнулся и сделал как принято, а не рассуждал на тему верно это или нет? Потому у гугла CS построен неверно, его только спасает выделение рассуждений в визуально отдельный блок и опытный читатель может его пропускать. Тем более рационализация гугла во многих местах смехотворна, лучше бы просто написали ~ заткись и делай как тут показано. > Можно, конечно, жить с херовой вики (как в Я) и пинать всех на ревью, а можно нормально описать. Рассказываешь сказки с несуществующими проблемами. Таких проблем нет даже в проектах, где исторически в разных местах появились разные CSы. Типичному разработчику всё же хватает интеллекта посмотреть как было до и сделать аналогично.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 02:32 , 16-Янв-24 (472)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 02:41 , 16-Янв-24 (473)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 20:02 , 19-Янв-24 (653)
> А в гугл берут тупых по твоей логике раз у них есть > гайдлайн? Чтож тогда яндексоиды пулей летят в гугл к тупым как > только получают офер?Судя по ряду проектов гугли - и их участи - типа, вот, фуксии - похоже что берут.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 00:00 , 16-Янв-24 (448)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 02:13 , 16-Янв-24 (468) –2
Выше рассуждаешь про вполне конкретную штуку - линуксовое ядро и c++ в нём. А значит и рассматривать должен ровно то, что там есть. Логично же, не так ли?> Можно хотя бы просто сравгить, что добавляет каждый новый стандарт С++ и С, и сделать из этого вывод о размере гайдлайна. Можно, но придётся опять включать мозг: большая часть изменений касается STL, которого в ядре не будет если туда завезут плюсы.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 03:04 , 15-Янв-24 (134) –1
AUTOBOT - это блочит (и я не знаю почему): А как они собираются исключения туда затянуть? (этого сделать вероятно не получится, да и не нужно) А без исключений затянут - это будет не C++, а просто "подмножество" C++ - типа "чуть улучшенный C". Ах да - это они всё ради темплэйтов наверное!P.S. А в Расте есть исключения?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 03:41 , 15-Янв-24 (147)
> Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядраЭто такой лол, что я даже не знаю, что сказать. Но когда пропадёт калабуховский дом, с рожей вонки буду сидеть.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., bOOster, 03:48 , 15-Янв-24 (148) +2
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 05:49 , 15-Янв-24 (161) +1
Да уж, беда пришла откуда не ждали... Если что-то и может быть хуже С, то это С++.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., n00by, 07:07 , 15-Янв-24 (168) –1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., ДаНуНафиг, 18:36 , 15-Янв-24 (370)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:56 , 15-Янв-24 (379)
Толпам молодёжи (и немоложёжи) вообще срать на ядро, они от него в принципе с удовольствием подальше держаться будут. Но не всегда есть такая опция. Драйвер сам не напишется... Нужен нормальный плюсовый фреймворк для драйверов.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., n00by, 15:43 , 16-Янв-24 (543)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Гультай, 09:03 , 19-Янв-24 (638)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., freehck, 07:51 , 15-Янв-24 (178)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 08:32 , 15-Янв-24 (182) +6 [^]
Я так подозреваю, что ядро на голой сишке писали, чтобы не было никакого неявного кода. По сути всем понятно, что любой ООП можно реализовать и без поддержки ООП в языке. На структурах и прописывая весь скрытый в ООП код ручками. Так возможно получится быстрее. Немного. Ну самый простой пример это managed строковые типы. Они безопаснее. Но они требуют динамического выделения памяти буквально на каждом шагу. А это на самом деле лишние тормоза. Чтобы не было никакого неявного тормозного кода - лучше юзать char*. Вы же знаете, что сегодняшних программистов учат в школе прогать на Питоне как обезьянок? Если им позволить юзать в ядре плюсы и stdlib - они ведь будут юзать самые тормозные конструкции, какие только можно. Они и PHP его бы на писали, если бы можно было.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 08:55 , 15-Янв-24 (185) –2
>По сути всем понятно, что любой ООП можно реализовать и без поддержки ООП в языке.Можно, но костыльно очень. Или хотите в ядро нечто, наподобие Glib? >На структурах и прописывая весь скрытый в ООП код ручками. Это человеконечитаемо, лапшакод. И зачем для каждого "класса" проделывать ручками одни и те же действия?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., n00by, 10:46 , 15-Янв-24 (220) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., freehck, 12:57 , 15-Янв-24 (268)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 15:43 , 15-Янв-24 (332) +1
c++ это не либа работы со строками. Причины совершенно в ином - нет API и нет гарантий на оптимизации сахара. Тем более если ещё брать c++ образца начала 2000, то вообще ужасный ЯП с минимум оптимизаций сахара компилятором.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., awoland, 08:59 , 15-Янв-24 (186) +2
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Noname, 09:50 , 15-Янв-24 (196) +2
- Дискуссия об использовании языка C++ для разработки ядра Lin..., beck, 10:23 , 15-Янв-24 (210)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 10:44 , 15-Янв-24 (218) –1
Не такой уж и зоопарк, всего полтора типа железа, которое в ней поддерживалось изначально. Зато её в бсод отправляет и открытие ютуба в браузере и сохранение файла в блокноте, про регулярно разлетающиеся файловые таблицы можно не вспоминать. Показательный уровень.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 10:46 , 15-Янв-24 (221)
Отличие кстати в том, что железо разрабатывают под ОС, потом костыляют адовые блобы с кучей костылей чтобы хоть как-то работало. В линуксе на помойные драйвера смотрят криво.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., beck, 10:51 , 15-Янв-24 (225)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 11:01 , 15-Янв-24 (232)
>Минимум шесть.Суть в том, что они там были испокон времён, ничего нового, и то на хлам с армом пришлось влить миллиарды миллиардов 15 лет назад, который всё равно оказался нежизнеспособным. >Windows не виновата в том, что у тебя лапки. Ну, тут виноваты windows update и неквалифицированные некомпетентные кадры в microsoft, не сама windows, понятное дело.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 06:52 , 16-Янв-24 (485) +1
> Зато её в бсод отправляет и открытие ютуба в браузере и сохранение файла в блокноте, про регулярно разлетающиеся файловые таблицы можно не вспоминать. Показательный уровень.Выкинь уже свой зион с али, с «ECC»-памятью.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., awoland, 14:37 , 15-Янв-24 (307)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., poulch, 09:09 , 15-Янв-24 (188) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 09:23 , 15-Янв-24 (191) –1
Зачем? ибо когда придёт какой-нибудь С++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!
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 10:58 , 15-Янв-24 (229) +1
Наверное, разработчикам ядра Linux все же виднее, зачем им нужен C++ и почему Раст для них не подходит.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 23:48 , 16-Янв-24 (595)
> какой-нибудь С++50, который наконец-таки превратится в RustТы думаешь, что в C++50 порежут все что можно по самые помидоры? Так что останется одна заготовка языка?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., d_kazbek, 09:40 , 15-Янв-24 (192) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Noname, 09:43 , 15-Янв-24 (193)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Tron is Whistling, 10:07 , 15-Янв-24 (203)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., ay8910, 11:22 , 15-Янв-24 (239)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 12:58 , 15-Янв-24 (271)
Человек не понимает, что ядро пишется корпорациями на деньги корпораций. Им и решать, какой язычок использовать, а какой - нет.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Tron is Whistling, 15:12 , 15-Янв-24 (320)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 20:26 , 15-Янв-24 (407)
Сходи к попам, посмотри на их кресты. Пойми, чем плюс отличается от креста.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 13:19 , 15-Янв-24 (274)
Но какую-то лёгонькую реализацию STL для целей внутри ядра, всё же, не помешает. Например, Vector и Array - большая польза. Хотя бы, чтобы за пределы буфера не выходить.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 13:35 , 15-Янв-24 (285)
> STL тоже придётся вымести, в основном из-за отсутствия единого аллокатора. Во всех контейнерах STL можно передавать собственные аллокаторы. Можно хоть для каждого аллокатора сделать свой набор классов, и это будет намного чище и безопасней дёрганий кошмарных malloc'ов и бесконечной ручной проверкой высвобождения всех сырых указателей. STL это вообще по большей части набор шаблонизированного кода, странно это не знать.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 15:47 , 15-Янв-24 (334)
Вместо STL будет своя либа с примитивами в c++ стиле. STL для ядерных целей не подходит
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Пряник, 10:16 , 15-Янв-24 (208)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., beck, 10:24 , 15-Янв-24 (212) +3
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Пряник, 10:29 , 15-Янв-24 (215)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 10:56 , 15-Янв-24 (228)
> windows > работаетНу, работать та работает. Но вот как работает...
- Дискуссия об использовании языка C++ для разработки ядра Lin..., beck, 11:00 , 15-Янв-24 (231) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 12:55 , 15-Янв-24 (266) –1
по-дефолту в плюсах нет инструментов для безопасной работы с памятью. RAII и smart поойнтерс - это совсем недавно любители плюсов нашкрябали, плюсы - сплошной ансейф. УРА товарщи!
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:26 , 15-Янв-24 (364) +1
> RAII ... was developed for exception-safe resource management in C++ during 1984–89Очнись, наркоша. Смарт поинтеры в плюсовых проектах уже более 30 лет в том или ином виде, до стандартного STLя доехали лет 13 назад.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 10:17 , 16-Янв-24 (494)
Ну ты и оболтус. Ну так по дефолту усё это выключено, в опенсорсе твоё стл никто не пользует. Твои плюсеги - сплошной ансейф, а когда находятся cve в плюсовых опенсорсах - разрабы отвечают: ну я забыл заюзать эту фичу. Ахахаха, плюсовеки, такие плюсоеки.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 12:52 , 15-Янв-24 (261)
Если так хорошо работает, почему везде линукс? Фактически сиплюсы используются только для игр. Винды - ось для запуска игр.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., beck, 13:43 , 15-Янв-24 (288) –1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 14:55 , 15-Янв-24 (312)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 15:55 , 15-Янв-24 (336)
Причем тут бизнес если даже бизнес-линукс, типа шапки мимикрирует под винду? 2 самых распространенных DE копируют решения из МАС оси и винды.Или ты хочешь, чтобы бедный врач пердолился с гентой или другими маргинальными дистрами? Искал дрова к специфическому оборудованию типа ЭЭГ/ЭКГ? В цивилизованных странах будет еще какая-то платформа для командной работы. Назови какое-то нормальное опенсорс решение (без шуток было бы интересно)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Tron is Whistling, 16:35 , 15-Янв-24 (344)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 17:18 , 15-Янв-24 (350)
Возможно, но например банкоматы я встречал на винде. Винда IoT Core вполне достаточно большому кол-ву медицинской техники. Я уже молчу про Windows CE)Хотя объективно для серьезного аппарата (типа радиотерапия или КТ) я бы постремался использовать ядро линукс. Уж лучше пусть будет какой-нибудь РТОС.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Tron is Whistling, 18:27 , 15-Янв-24 (365)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Tron is Whistling, 18:28 , 15-Янв-24 (366)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 20:07 , 19-Янв-24 (654)
> Банкомат - слишком примитивное устройство. Дисплей, кейпад, принтер и полтора ком-порта > для кард-ридера и денег.У одной фирмы я видал там характерную лужайку с кнопкой Start. Или, не менее пафосный скринсейвер с логотипом XP. А у другой после проскока питалова - вся загрузка как на ладони, но там еще после старта антивирь пашет. И пока он пашет - тадам - можно шарахаться по морде банкомата жамкая сенсорный экран, проводник точно запускается. Потом конечно морда запускается и все вышибает, но пошариться проводником по банкомату... ээ... ну им так кто-нибудь и бабки снимет при случае наверное. В мои планы такой тупой кибекриминал не входил, чисто проверка "так можно было?!", но оказалось что таки - можно! :)))
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 17:37 , 15-Янв-24 (353)
Не хочется тебя расстраивать, но бизнесу нужно чтобы всё просто работало за минимальную стоимость, ничего личного. Будет это линукс, винда, или ещё что-то - бизнесу неважно. А построением мирового open-source коммунизма пусть занимается кто-то другой.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Tron is Whistling, 16:32 , 15-Янв-24 (342) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Tron is Whistling, 16:33 , 15-Янв-24 (343)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 19:17 , 15-Янв-24 (392)
>Я прихожу к врачам, в мрт винда, на рентгене винда, в аппарате узи винда.Потому, что в Скрепной медоборудование закуплено 15-летней назад разработки? А то и ваще б/у.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 17:39 , 15-Янв-24 (354) +2
Ядро винды написано на Си
- Дискуссия об использовании языка C++ для разработки ядра Lin..., хрю, 14:53 , 16-Янв-24 (529) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вирт, 11:26 , 15-Янв-24 (242) –1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 13:41 , 15-Янв-24 (286)
> И с тех пор C++ стал хуже, появилось еще 100500 способов выстрелить себе в ногу.Все способы выстрелить себе в ногу в C++ - это исключительно наследие C. На чистом плюсовом коде (без сырых указателей, сишных строк и функций) выстрелить себе в ногу очень сложно. Правда сишники начинают беситься от ошибок компилятора, и начинают в обход компилятора фигачить свой сишный код, это да.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 15:00 , 15-Янв-24 (314)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 00:09 , 16-Янв-24 (454)
> Все способы выстрелить себе в ногу в C++ - это исключительно наследие > C. На чистом плюсовом коде (без сырых указателей, сишных строк и > функций) выстрелить себе в ногу очень сложно.А дебильные классические типы целых чисел там как? Их так то и в си неплохо бы выпилить к хренам и сделать по уму, на основе C99 - и с "well defined behavior". Это спасло бы от дохреналиона багов и вулнов на ровном месте. И да - вообще забанить к хренам "int" (signed) как индексы. С расстрелом из реактивного г@вномета за это. Чтобы господам даже чисто теоритически в голову не приходило что в массив можно отрицательный индекс, бдаж!
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Tron is Whistling, 11:26 , 16-Янв-24 (502)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Fyjy, 13:41 , 16-Янв-24 (512) –1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Tron is Whistling, 13:51 , 16-Янв-24 (519)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 14:45 , 16-Янв-24 (527)
Так твой пример сам по себе небезопрасный. И на этот случай есть унарный --, знак тут всё ещё не нужен
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 20:15 , 19-Янв-24 (656) –1
> Вот есть у меня вот прямо индекс указателей на элементы. Есть поинтер > на какой-то указатель в этом индексе. > Мне надо предыдущий взять. Далее чего?Уволить того кто код так пишет к хренам - зачем вам этот генератор CVE в тиме?
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Tron is Whistling, 21:41 , 19-Янв-24 (658)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 12:44 , 20-Янв-24 (665)
> Да не, я не против, чтобы ты вместо одного сервера у меня > 10 купил, но ты ведь не купишь.Я как махровый сишник готов поспорить что все то же самое можно было сделать значительно менее ректально. Без явно невалидных на глаз (и статический анализатор) действий. То что вы делаете что-то ректально и гордитесь этим намекает что хрустики все же имеют свой понйт в своем желании вас уйти. Той е#$%нины в коде лично я не желаю видеть в принципе.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 20:12 , 19-Янв-24 (655) –1
> Ты не поверишь, но отрицательный индекс в массиве по указателю - очень > даже востребован.А вот эксперты по фигурному прострелу пяток с заподвыподвертом пожаловали. Я все понимаю - но вот в именно таком стиле CVE получаются. Воон там зубр сабмитил отрицательный индекс массиву если вооон те параметры на вход дать. Не, так не задумано - просто он аргументы функции на вход не чекал, и получив воооон те параметры, лихо проматывал индекс не только до 0 но и за него. Ну, подумаешь, по чужой памяти пошарился, а то и в провод слил, "ишь ты, карманный вариант heartbleed'а". Гнать таких програмеров ссаными тряпками и ср@ной метлой.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Fyjy, 13:44 , 16-Янв-24 (514)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., nc, 11:47 , 15-Янв-24 (247)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 12:39 , 15-Янв-24 (254)
Да, только раст спасёт ведро линукс!
- Дискуссия об использовании языка C++ для разработки ядра Lin..., nc, 12:53 , 15-Янв-24 (262) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Серб, 13:57 , 15-Янв-24 (294) –1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., nc, 15:40 , 15-Янв-24 (331)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 15:56 , 15-Янв-24 (337)
Это само по себе хорошо т.к. не нужно править дохринилиард прагм во всём репозитории при переходах на новые стандарты. Дерьмовее предложения, чем помечать каждый исходник версией, просто невозможно придуамать.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _oleg_, 16:56 , 16-Янв-24 (561)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Серб, 17:14 , 16-Янв-24 (563)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _oleg_, 18:06 , 16-Янв-24 (568)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Серб, 18:18 , 16-Янв-24 (571)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _oleg_, 18:51 , 16-Янв-24 (572)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Серб, 12:46 , 17-Янв-24 (617)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _oleg_, 13:20 , 17-Янв-24 (618)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Серб, 13:43 , 17-Янв-24 (619)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Серб, 13:48 , 17-Янв-24 (620)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Серб, 16:49 , 15-Янв-24 (346)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 15:58 , 15-Янв-24 (338) +1
> Компиляторы бы поддерживали сразу несколько версий, в результате программисты бы спокойно переходили на новые версии и по мере возможностей подтягивали бы старый код.В результате программисты просто бы никуда не переходили. Совместимость со старыми стандартами и так достаточно глубокая по вермени. Проблемы обычно возникают с некорректным использованием поюсов.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 15:52 , 15-Янв-24 (335) +3
rust разработан с учётом надёргивания из маргинальных ЯП фич, которые очень хотелось подёргать хипстерам из команды разработчиков. Другими словами, разработан с учётом опыта языков с низким практическим применением.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _oleg_, 16:48 , 16-Янв-24 (559)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 13:01 , 15-Янв-24 (272) –1
>метапрограммирование >произвольные вычисления во время компиляции >безопасная работа с памятьюЧего только не сделают, лишь бы переизобрести лисп в своем языке... Отправляйте всех любителей оного в нашу палату, пусть лучше на человеческом языке Mezzano OS пилят, а не гробят Линукс своими прогрессивными франкенштейнами.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним12345, 14:28 , 15-Янв-24 (301) +2
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Миллион глаз, 17:53 , 15-Янв-24 (355) [V]
- Дискуссия об использовании языка C++ для разработки ядра Lin..., DEF, 18:05 , 15-Янв-24 (359) –2
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 18:35 , 15-Янв-24 (369) +1
Никаких новых парадигм в расте нету.Тогда уже лисп давайте
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 19:04 , 15-Янв-24 (386) +1
1. Раст требует грёбанного тулчейна. 2. Хотя-бы потому, что на крестах доступны растопримитивы и это позволит инкрементно переводить код на раст. То есть сначала потихоньку сишный код переписывается на кресстовый. Потом крестовый приводится к растоподобному стилю. Потом переписывается на раст, фиксятся баги компиляции, фиксы бэкпортируются на кресты. Каждый патч проходит ревью. Тем самым обеспечивается преемственность, последовательность и контроль на каждом этапе.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _oleg_, 16:47 , 16-Янв-24 (558)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 17:25 , 17-Янв-24 (627)
>Да что это за болезнь такая тащить всё модное всюду без разбора?Обычная болезнь зумеров. Знаний - мало, энергии - много, страсть ко всему новому (для их мозга). Увидели - слюни потекли, побежали ставить/канпелять. Плюс, такие же клоуны как они подливают масла в огонь своими "хелловорлдными" статейками (которыми только подтереться). И вот уже кто-то всерьёз обсуждает Раст.... *фэйспалм*
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Товарищ, 18:57 , 15-Янв-24 (381) +2
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 03:18 , 16-Янв-24 (480)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., хрю, 14:57 , 16-Янв-24 (532)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 15:25 , 16-Янв-24 (535) +1
Я зол. В низкоуровневых разработках нет места объектно-ориентированным языкам. Си плюс-плюс запретить. Всё! Такие вопросы вообще не должны обсуждаться.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 16:20 , 16-Янв-24 (552) –1
Но поскольку разработчикам ядра Linux виднее, что им делать, обсуждение перехода ядра на C++ продолжается, а ты можешь и дальше писать свои бессильные гневные комментарии.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _oleg_, 16:43 , 16-Янв-24 (556) +1
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Вы забыли заполнить поле Name, 23:11 , 16-Янв-24 (588)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., DEF, 23:26 , 16-Янв-24 (592)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _oleg_, 11:18 , 17-Янв-24 (612)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 17:21 , 17-Янв-24 (626)
Например, в D (чистый преемник С++). Нет множ.наследования (порождающие больше проблем, чем решающие). Есть traits. Шаблоны. Да вообще ВСЁ, что может понадобиться адекватному ООПщику - чего не пишется, спрашивается??
- Дискуссия об использовании языка C++ для разработки ядра Lin..., _oleg_, 16:41 , 16-Янв-24 (555)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 04:39 , 17-Янв-24 (605)
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 07:04 , 17-Янв-24 (606) +3
Приводить Майкрософт (компанию, которую все презирают), как пример для подражания. Ну, это даже не шутка, это жирнейший троллинг.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 17:16 , 17-Янв-24 (625) +1
То, что в M$ работают индусские м@к@ки, порождает и соотв. решения - вот Раст к примеру :)) Абсолютно необоснованное решение. Как и попытки заигрывания в Линукс внутри венды. Сейчас M$ далеко не "гигант ИТ" - это монстр, который полностью сгнил внутри и идёт чисто как зомби - по инерции. Венда-10-11 - это очевидный тупик, забагованный больше алкашного дивана. .NET Core движется в ___еня. Студия не развивается толком, т.к. требуется ПОЛНОЕ переписывание. На плаву держатся серверные системы и MS SQL (видимо, обезьян не подпускают к золотой курице).Другими словами, найдите пример поинтереснее.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 20:20 , 19-Янв-24 (657) +2
> внутри и идёт чисто как зомби - по инерции. Венда-10-11 - > это очевидный тупик, забагованный больше алкашного дивана. .NET Core движется в > ___еня. Студия не развивается толком, т.к. требуется ПОЛНОЕ переписывание.Да это вы просто не видели что они с виндофоном вытворяли. Еще и нокию за собой утопили, угробив все наработки UI/UX от нокии, с...ки!
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 14:41 , 17-Янв-24 (621)
Заскорузлые мозги => устаревшие решения.Почему не D ?? Для кого развивали "преемника С++"? Там же всё по-уму сделано, а популяризация его в линукс-камьюнити только ещё больше поможет языку.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 13:34 , 20-Янв-24 (667)
Вкатывающимся ядроразрабам помимо знания сишки нужно будет отлично знать кресты с их шаблонной магией и прочими непотребствами стандарта на много тысяч страниц. Таким образом резко повышается порог вхождения.
- Дискуссия об использовании языка C++ для разработки ядра Lin..., Аноним, 03:53 , 21-Янв-24 (671)
С++ и С имеют множества недостатков от которых некоторые современные языки вылечены. Проблема в том что разработчики компиляторов и железа в первую очередь поддерживают С,С++ и в стандартизации — разных поставщиков и наборе инструментов. Поэтому выигрывает тот язык, который сумеет буквально его поглощать трансляцией в другой язык. Таких пока вроде нет и вряд ли будет — из-за множества ньюансов дешевле нанять команду разработчиков которые будут переводить из С на свой язык библиотеки и фреймворки. А вот локальные миссии по созданию цифровой экосистемы могли бы дать результат, если целенаправленно двигаться лет так 10–15. Но миссии это у американцев, потому что у них agile процессы.
|