Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Дискуссия об использовании языка C++ для разработки ядра Linux"	+/–
Сообщение от opennews (??), 14-Янв-24, 21:43
В списке рассылки разработчиков ядра Linux возобновилось начатое шесть лет назад обсуждение перспектив использования современного кода на C++ в ядре Linux, помимо нынешнего применения языка Си с ассемблерными вставками и продвижения языка Rust. Изначально тема разработки ядра на C++ была поднята в 2018 году инженером из Red Hat, который первого апреля в качестве шутки опубликовал набор из 45 патчей для использования шаблонов, наследуемых классов и перегрузки функций C++ в коде ядра... Подробнее: https://www.opennet.me/opennews/art.shtml?num=60436
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

62. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–25 +/–
Сообщение от _kp (ok), 14-Янв-24, 23:42
Пока с++ не осилит инициализацию структур, говорить о переносе кода безполезно, ибо сизифов труд.
Ответить | Правка | Наверх | Cообщить модератору

	75. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (75), 15-Янв-24, 00:03
	О чем речь? С++ может инициализировать структуры
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (75), 15-Янв-24, 00:07
	struct A {   int a;   int b; }; A a1{1, 2}; работает в C++20 (может и в более ранних версиях)
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	244. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от _kp (ok), 15-Янв-24, 11:30
	a1{1, 2}; Вот не надо подобного. Когда полей в структуре не один десяток, получим нечитаемый говнокод и хорошими шансами на вагон опечаток. a1{.v1=1, .v2=2} - работает в с++, но частично. Давится на порядок полей, и к тому что считает константами. И подобное с Си в С++ не переносится без правки исходника.
	Ответить | Правка | Наверх | Cообщить модератору

	513. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (-), 16-Янв-24, 13:43
	>  a1{1, 2}; > Вот не надо подобного. Когда полей в структуре не один десяток, получим > нечитаемый говнокод и хорошими шансами на вагон опечаток. И хотя это правда, стоит добавить: когда в структуре столько полей - мы знаем что программер/архитект где-то сказочно облажались. Когда у вас столько полей, линейным списком, вы что-то сделали не так. Что, даже вложенный struct не смогли? Или это и правда плоский список такого размера? Что бы это могло быть в легитимном виде, когда того кто это сделал не надо бы уволить с треском за вот это все?
	Ответить | Правка | Наверх | Cообщить модератору

	525. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (525), 16-Янв-24, 14:32
	Начнём с того, что вложенные структуры конкретно данную проблему не исправят, а только добавят скобочек в визуально случайных местах инициализации структуры. Продолжим тем, что глупо добавлять структуры только для того, чтобы уменьшить число полей в каждой из них. Это вам не Ява, где шаг вправо-шаг влево - и у вас сонаркуб заругается, что в структуре больше двух полей, давайте, разбивайте на несколько структур, даже если смысла в этом нет, просто первую половину полей в одну структуру, вторую половину - во вторую. И закончим на соседней новости, где просто изменением порядка полей в большой структуре добились увеличения производительности на 40%. В случае со вложенными структурами эта оптимизация была бы где-то в диапазоне от "выглядит бредово" до "это невозможно".
	Ответить | Правка | Наверх | Cообщить модератору

	644. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 19-Янв-24, 18:18
	> Начнём с того, что вложенные структуры конкретно данную проблему не исправят, а > только добавят скобочек в визуально случайных местах инициализации структуры. Вообще-то сделают данные более структурированные - и - вот - менее подверженными тому классу ошибок. Если вы это не понимаете - что я там про архитектов то говорил? Вывалить более 9000 сущностей линейным списком не больно какая архитектура. > Продолжим тем, что глупо добавлять структуры только для того, чтобы уменьшить число > полей в каждой из них. Это вам не Ява, где шаг > вправо-шаг влево - и у вас сонаркуб заругается, Ну так правильно заругается. Нефиг гамнокодить. Структуры с дохреналионом полей уж точно не признак мастерства архитекта и изящества архитектуры. > что в структуре больше двух полей, давайте, разбивайте на несколько структур, > даже если смысла в этом нет, просто первую половину полей в одну структуру, вторую > половину - во вторую. Со своей стороны я буду считать что более ~десятка полей в структуре - "кодер был неадекватен и делал какую-то фигню или не смог в архитектуру, гамнякая в режиме питоняши". > И закончим на соседней новости, где просто изменением порядка полей в большой > структуре добились увеличения производительности на 40%. А вот там господа таки - понимают что делают - и структур  с более 9000 полей не заводят. И вложенные структуры юзать не гнушаются. Такая ерунда. > В случае со вложенными структурами эта оптимизация была бы где-то в диапазоне > от "выглядит бредово" до "это невозможно". С чего бы это вдруг? А 1 из примеров - заменили struct на u32. Стало даже проще. На самом деле есть tradeoff между нуждами оптимизации кода и изящностью и логической консистентностью апи. Не всегдя изящное логичное апи хорошо маппится на конкрерику оптимизера вот тут. Тот кто не джун и уже умеет в архитектуру и управление проектом немного - понимает что нужен какой-то разумный баланс. Если у вас более 9000 полей в структуре, очевидно, это профачено.
	Ответить | Правка | Наверх | Cообщить модератору

	578. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 16-Янв-24, 20:06
	>>Когда у вас столько полей... вы что-то сделали не так. Что значит мы? Это задачи такие. И не все делается в одиночку. Что требуется для работы с устройствами и протоколами. А в итоге, иногда, строки в исходнике распухают за 400 символов. ;) Отформатируешь, так будет каша, в которой не разобраться. Впрочем, что где то плохо спроектировано я соглашусь. Матерюсь же. ;)
	Ответить | Правка | К родителю #513 | Наверх | Cообщить модератору

	645. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 19-Янв-24, 18:33
	> Что значит мы? Это задачи такие. Ну да, вы такие особенные на всю планету, наверное. > И не все делается в одиночку. Значит общее управление проектом оставляло желать. То что факап по чуть другой линии не означает что это офигенная идея и так и надо было. > Что требуется для работы с устройствами и протоколами. > А в итоге, иногда, строки в исходнике распухают за 400 символов. ;) Типа, когда это УГ надо скроллить даже на здоровенном мониторе - намного понятнее и читабельнее? Более того - это нехило ограничений на конфиги тех кто в проекте будет копаться. В опенсорсе чревато тем что вам вообще патчей не пришлют, решив что скроллякать ваши простыни на вон том лаптопе - нафиг надо, лучше другой код взять, менее отшибленый. > Отформатируешь, так будет каша, в которой не разобраться. ORLY? У меня другие идеи на этот счет. Сорри. В случае опенсорса, если я где-то такое встречу, я просто немедленно сотру это как непотребное, если есть замена, или жестко отрефакторю, если по другому совсем никак. Потому что такой гамнякинг для меня приемлимым не является. > Впрочем, что где то плохо спроектировано я соглашусь. Матерюсь же. ;) Ну дык, иногда бывает что ну вот оставляет желать, но это ж не пример как надо делать. А пример как делать НЕ надо. Чтобы другие потом не матерились на такой код.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 15-Янв-24, 00:42
	> Пока с++ не осилит инициализацию структур, говорить о переносе кода безполезно, ибо > сизифов труд. Эй, это даже в си работает?! Вы там что-то совсем тормоз не отпустили? Черт, даже можно присваивать однотипные структуры. Одна из причин по которым gcc в freestanding надо memcpy - конечно же такое присвоение это вот оно будет.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	115. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+5 +/–
	Сообщение от Аноним (115), 15-Янв-24, 02:23
	В смысле, 'даже'? В плюсах эта фича полноценно появилась только в C++20, когда как в Си с C99 https://en.cppreference.com/w/cpp/language/aggregate_initial...
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (149), 15-Янв-24, 03:49
	a = {.x = 1, .y = 2}; Вот такой синтаксис завезли только в 20е плюсцы.
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	240. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 15-Янв-24, 11:24
	> > a = {.x = 1, .y = 2}; > > Вот такой синтаксис завезли только в 20е плюсцы. Ага.  А если не в исходнике было не {.x = 1, .y = 2, ...}, а в другом порядке { .y = 2, .x = 1, ...}, то надо править исходник, иначе не скомпилирует.
	Ответить | Правка | Наверх | Cообщить модератору

	363. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
	Сообщение от ДаНуНафиг (?), 15-Янв-24, 18:23
	Все правильно, ибо нефиг создавать ложное впечатление, есть же строгий порядок инициализации.
	Ответить | Правка | Наверх | Cообщить модератору

	469. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 16-Янв-24, 02:21
	> нефиг создавать ложное впечатление, есть же строгий порядок инициализации. Если сам с нуля пишешь то обычно да, логичнее писать по порядку, но бывает используется препроцессор, когда изменяемую часть надо выделить, то порядок меняется. И конечно уже существующие исходники. Не забываем, что инициализацию структур только только добавили. И еще недавно можно было для больших структур делать или нечитаемую портянку, и как дурак считать каждый раз элементы, что б что то исправить, или мешать с и c++ файлы в проекте. Шаг в сторону улучшения есть, что хорошо, но пока полумеры.
	Ответить | Правка | Наверх | Cообщить модератору

	643. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от ДаНуНафиг (?), 19-Янв-24, 16:38
	>> нефиг создавать ложное впечатление, есть же строгий порядок инициализации. > Если сам с нуля пишешь то обычно да, логичнее писать по порядку, > но бывает используется препроцессор, когда изменяемую часть надо выделить, то порядок > меняется. Все это прекрасно выделяется блоками комментариев. Не могу представить ситуации с перестановкой блоков инициализации, чтобы это выделить. > И конечно уже существующие исходники. В существующих исходниках ничего не поменяется. А если уж хочется их "освежить" подобной инциализацией, то можно же предварительный корректирующий коммит сделать. > Не забываем, что инициализацию структур только только добавили. И еще недавно можно > было для больших структур делать или нечитаемую портянку, и как дурак > считать каждый раз элементы, что б что то исправить, или мешать > с и c++ файлы в проекте. > Шаг в сторону улучшения есть, что хорошо, но пока полумеры. Для сложных случаев всегда можно было каждый инициализатор сопровождать маленьким блочным комментарием с имененем инициализируемого члена класса. Больше забот, но в сопровождении уж насколько проще. Хотя если разобраться, что в комментарии написать /* id */, что так написать .id=0  - практически один фиг ведь по количеству символов.
	Ответить | Правка | Наверх | Cообщить модератору

	646. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 19-Янв-24, 18:34
	> Все это прекрасно выделяется блоками комментариев. Да это ж это же костылизм. Впрочем, сейчас оно уже в прошлом. > Не могу представить ситуации с перестановкой блоков инициализации Да легко. Переставили в какой ни будь библиотеке параметры в структуре, и что теперь собирающийся под разные варианты исходник корежить, и делать несколько его вариантов. А в embedded это не редкость, и при сборке под разные платформы тоже. И туда же, как писал выше, генерация макросами. И так же, заполнение не всех полей балластом, когда их много.
	Ответить | Правка | Наверх | Cообщить модератору

	672. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от ДаНуНафиг (?), 21-Янв-24, 07:41
	>> Не могу представить ситуации с перестановкой блоков инициализации > Да легко. Переставили в какой ни будь библиотеке параметры в структуре, и > что теперь собирающийся под разные варианты исходник корежить, и делать несколько > его вариантов. А в embedded это не редкость, и при сборке > под разные платформы тоже. > И туда же, как писал выше, генерация макросами. > И так же, заполнение не всех полей балластом, когда их много. Ничего не понял про собирающего. Если у него были старые исходники, то у него все поля инициализировались в строгом порядке вообще без указания поля, например: a{0, 2, 3}. Даже если ему придет в голову самолично переключить стандарт компиляции на C++20, то этот же код соберется без проблем, по крайней мере в этой части.
	Ответить | Правка | Наверх | Cообщить модератору

	249. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
	Сообщение от _kp (ok), 15-Янв-24, 11:55
	Я сейчас почти не пишу драйверы, но когда то писал. Сейчас в основном под встраиваемые контроллеры пишу. Принципиальная разница инициализации структур с Си,в том что это и занимает 0 тактов, в отличии от конструкторов, и более того не требует временных переменных, что облегчает автоматизацию генерации кода. Вне ядра проблема "элегантно" решается мешаниной файлов C и C++ в одном проекте. Каких то причин, кроме религиозных убеждений, доя подобной несовместимости, и подобных - нет. И в идеале было бы хорошо, если бы компилятор C++ был чуть более совместимым с С. О другой проблеме - совместемости вызовов. Частичное решение - extern "C". И напрашивается добавить аналогичное extern "CPP", как стандартизированный вариант для API и библиотек.
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	305. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 15-Янв-24, 14:35
	> Принципиальная разница инициализации структур с Си,в том что это и занимает 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ообщить модератору

	505. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 16-Янв-24, 11:37
	Вы предлагаете в структуры напихать методов на все случаи? Только описывать их придется в одном месте, а вызывать из другого. Ну удобно же, и читаемо.  :) А подобную инициализацию в портянки переписывать? C++ это не переваривает.   test1("Test1", &(const rqtm_t){.base = 1000, .answer1 = 150, .reaction = 2000, .transfer = 0, .rw = 0 });   test1("Test2", &(const rqtm_t){.base = 500, .answer1 = 50, .reaction = 100, .transfer = 80, .rw = 32 });   .. > В конечном итоге хруст, а вроде еще D, и кто там еще Так, идея в поддержке Си - исходников, а не переписывании.
	Ответить | Правка | Наверх | Cообщить модератору

	581. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от adolfus (ok), 16-Янв-24, 20:24
	В С и С++ нет методов, не было никогда и не будет -- есть функции-члены.
	Ответить | Правка | Наверх | Cообщить модератору

	599. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 17-Янв-24, 04:04
	> Вы предлагаете в структуры напихать методов на все случаи? Я лишь констатировал что на си можно делать весьма по разному - в том числе даже и фокус на манер конструктора, вот, отколоть. Иногда даже может иметь свой пойнт. Нужно ли делать именно так в конкретном случае - на усмотрение програмера. > удобно же, и читаемо.  :) Ну извините, в сях в общем случае принято допустим 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.
	Ответить | Правка | К родителю #505 | Наверх | Cообщить модератору

	341. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (341), 15-Янв-24, 16:29
	> Принципиальная разница инициализации структур с Си,в том что это и занимает 0 тактов, в отличии от конструкторов А можно пример, чтобы это было так не только с -O0? Зачем компилятору вызывать конструктор, когда он может применить оптимизации? Можно этот переделать: https://godbolt.org/z/Y4G554zdr
	Ответить | Правка | К родителю #249 | Наверх | Cообщить модератору

	580. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (341), 16-Янв-24, 20:20
	А, методы, определённые в теле класса, неявно помечены как inline. Если определения конструкторов вынести - новое условие уже будет "чтобы это было так не только с -O0/-O1".
	Ответить | Правка | Наверх | Cообщить модератору

	352. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от pavlinux (ok), 15-Янв-24, 17:21
	> ... почти не пишу драйверы, но когда то писал. Сейчас в основном под встраиваемые контроллеры пишу. >  аналогичное extern "CPP", Пейсатель,  CPP - это C PreProcessor,   CXX - для плюсов )))
	Ответить | Правка | К родителю #249 | Наверх | Cообщить модератору

	367. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от ДаНуНафиг (?), 15-Янв-24, 18:29
	Про 0 тактов - constexpr ctor.
	Ответить | Правка | К родителю #249 | Наверх | Cообщить модератору

	373. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 15-Янв-24, 18:45
	consteval
	Ответить | Правка | Наверх | Cообщить модератору

	471. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 16-Янв-24, 02:31
	> Про 0 тактов - constexpr ctor. 1. Да, я это использую. Но не так и редко бывает на ровном месте и constexpr variable must be initialized by a constant expression Особенно во встраиваемом ПО,что по духу ближе к ядру, чем пользовательские приложения. 2. После обкладывания constexpr всего и вся правда ведь исходник и красивей и читаемей? Поэтому, использую не в всегда.
	Ответить | Правка | К родителю #367 | Наверх | Cообщить модератору

	474. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 16-Янв-24, 02:47
	> constexpr variable must be initialized by a constant expression На сях для тактов вы тоже либо скроите эквивалентное по смыслу, либо это не 0 тактов получится. За 0 тактов только то что удалось в константу сколлапсить, для чего оно должно быть вычисляемо на этапе компила. Иначе фиг тебе, золотая рыбка.
	Ответить | Правка | Наверх | Cообщить модератору

	492. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 16-Янв-24, 10:13
	constexpr и задумано для этого. Не спорю. Но где то не применимо. Хотя в большинстве случаев и предпочтительнее и мощнее. Смысл пожеланий о ициализации, в том, что бы с++ компилятор переваривал исходники Си без их правки. Это не тяжелое изменение. А переезд могло бы сильно облегчить.
	Ответить | Правка | Наверх | Cообщить модератору

	600. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 17-Янв-24, 04:09
	> constexpr и задумано для этого. Не спорю. > Но где то не применимо. Хотя в большинстве случаев и предпочтительнее и мощнее. Как бы плюсы мощнее сей. Но если повыпендриваться - то си можно основательно перекроить. Но не факт что нужно, ибо огорошивать посторонних кодеров экзотичным диалектом... не очень хорошая идея. Хотя о C++ ходит даже в общем то и не шутка что каждый програмер пишет на своем диалекте C++. > Смысл пожеланий о ициализации, в том, что бы с++ компилятор переваривал исходники > Си без их правки. На 100.0% это все же врядли получится. Скажем "register" в C++ нету. И auto означало нечто совсем другое до недавних пор. Хоть я и не понимаю чем им "register" так уж не угодил. > Это не тяжелое изменение. А переезд могло бы сильно облегчить. Вот конкретно там я тоже не понимаю почему вообще должно быть такое отличие.
	Ответить | Правка | Наверх | Cообщить модератору

	642. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от ДаНуНафиг (?), 19-Янв-24, 16:29
	> 2. После обкладывания constexpr всего и вся правда ведь исходник и красивей > и читаемей? > Поэтому, использую не в всегда. Красивее - нет, но оно и не всегда нужно, а когда и вовсе нужно убирать.
	Ответить | Правка | К родителю #471 | Наверх | Cообщить модератору

	450. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от InuYasha (??), 16-Янв-24, 00:03
	А что плохого в extern "C"? Очень часто используется.
	Ответить | Правка | К родителю #249 | Наверх | Cообщить модератору

	554. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от анон (?), 16-Янв-24, 16:27
	> в отличии от конструкторов это не совсем так. placement new в C++ может инициализировать объекты по адресу в буфер. и также возможны свои реализации аллокаторов static char buffer[128]; new (buffer) Circle()
	Ответить | Правка | К родителю #249 | Наверх | Cообщить модератору

	579. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 16-Янв-24, 20:19
	> new (buffer) Circle() Благодарю. Жаль что с constexpr оно только с c++20 только, а то в embedded в ходу компиляторы и постарее. Но, уже лучше.
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (236), 15-Янв-24, 11:16
	> ибо сизифов труд Есть же знатоки.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	241. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 15-Янв-24, 11:26
	>> ибо сизифов труд > Есть же знатоки. А что не так? Если ни какими опциями компилятора нельзя избежать правки рабочего исходника и внесения новых опечаток, то вполне мартышкин труд.
	Ответить | Правка | Наверх | Cообщить модератору

	325. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Котофалк (?), 15-Янв-24, 15:30
	Строго говоря разница усматривается. Сизифов труд это бесконечное наказание, мартышкин труд - бесполезное развлечение.
	Ответить | Правка | Наверх | Cообщить модератору

	270. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от leap42 (ok), 15-Янв-24, 12:57
	>> Пока с++ не осилит инициализацию структур С++ поддерживает 25 способов инициализации, и это уже само по себе проблема)
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	293. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 13:52
	В 20 сишную .fild_name=100 запилили.
	Ответить | Правка | Наверх | Cообщить модератору

1. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–17 +/–
Сообщение от Аноним (1), 14-Янв-24, 21:43
Нельзя туда цпп. Ладно модули, только не ядро. Запаримся пересобирать же! Си собирается намного шустрее.
Ответить | Правка | Наверх | Cообщить модератору

	2. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от oficsu (ok), 14-Янв-24, 21:46
	Там жалобы есть в том числе на макросы. А они вполне себе могут компилиться дольше, чем какие-нибудь шаблоны, решающие ту же задачу
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
	Сообщение от Аноним (18), 14-Янв-24, 22:08
	>Там жалобы есть в том числе на макросы. А они вполне себе могут компилиться дольше, чем какие-нибудь шаблоны, решающие ту же задачу ШТО? Макросы, в отличие от шаблонов цпп, не обладают тьюринговой полнотой. Это шаблоны можно заставить компилироваться сколь угодно долго.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
	Сообщение от funny.falcon (?), 14-Янв-24, 23:20
	> не обладают тьюринговой полнотой Но остаётся совсем чуть-чуть до этого. https://github.com/Hirrolot/metalang99 https://jadlevesque.github.io/PPMP-Iceberg/ Я сделал на шаблонах довольно мощную штуку с объектным программированием на C. И оно компилится действительно очень долго. Кроме TCC, он быстр даже в этих шаблонах. Правда, чуть-чуть бажит.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+4 +/–
	Сообщение от Аноним (-), 14-Янв-24, 23:41
	> Я сделал на шаблонах довольно мощную штуку с объектным программированием на C. > И оно компилится действительно очень долго. А я сделал себе верификацию ряда операций в компилтайме, скажем что я в 32 бит регистре не трогаю 35-й бит. Почти хруст получился. Даже не тормозит особо. В сабже кстати есть зачатки этого добра откуда я и содрал идею. Хотя круче всего это в Zig сделано - там можно компил тайм предвычисления юзая стандартный синтаксис яп. Плюсы в этом смысле - убогие полумеры, ибо препроцессор с отдельным синтаксисом никуда не делся. А какой-нибудь constexpr знатный горбыль так то.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (-), 14-Янв-24, 23:32
	> Макросы, в отличие от шаблонов цпп, не обладают тьюринговой полнотой. > Это шаблоны можно заставить компилироваться сколь угодно долго. Они ну вот буквально на грани :). Единственный лимит - рекурсия до 128, чтоли, уровней в GCC разрешена. Но с таким количеством рекурсии можно основательно позажигать.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	69. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от oficsu (ok), 14-Янв-24, 23:48
	> Это шаблоны можно заставить компилироваться сколь угодно долго Да, можно. Но это рассуждение об экстремальных примерах. Но экстремальные примеры — скорее редкость. Дуплицирование кода от макросов способно замедлять компиляцию точно так же, как и шаблоны. И способно иногда замедлять её даже сильнее при решении аналогичных задач
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	214. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (214), 15-Янв-24, 10:28
	Тормозящие шаблоны целиком типичная ситуация в 100% проектов. Программы на этом языке компилируются дольше всего.
	Ответить | Правка | Наверх | Cообщить модератору

	408. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (293), 15-Янв-24, 20:31
	Шаблоны это compile time. Ну и хрен с ними, сколько им компиляться. Главное, чтобы потом сгенерённый код быстро работал.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Bottle (?), 14-Янв-24, 22:29
	А ещё макросы не анализируются также хорошо как шаблоны через статический анализ.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	4. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+5 +/–
	Сообщение от Аноним (4), 14-Янв-24, 21:47
	Так пусть определятся для начала. Если rust можно, то почему плюсы нельзя?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	32. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от _hide_ (ok), 14-Янв-24, 22:36
	А кто сказал, что раст можно? Пока что раст -- это для модулей, которые с ванилью собирать не обязательно
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Витюшка (?), 14-Янв-24, 23:18
	Это сказал Линус в интервью, что ожидается большее использование в базовых компонентах ядра. Те модули - это пока, проба пера.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (107), 15-Янв-24, 02:09
	Только в драйверах и может быть в файловых системах, и то если все хорошо пойдет.
	Ответить | Правка | Наверх | Cообщить модератору

	204. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Герман (??), 15-Янв-24, 10:07
	Потому что плюсы слишком громоздкие, много неявного поведения, имеется наследование классов, шаблоны. Чудовище Франкенштейна самое настоящее. В ядре такое - недопустимо, лишнее усложнение не нужно, высока цена ошибки Раст же, как и Си, - прост. Да, раст посложнее Си по части обучения, но проще плюсов, и он предоставляет множество гарантий безопасности, чего нет в плюсах
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	252. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (252), 15-Янв-24, 12:21
	>гарантий безопасности Какие тебе гарантии нужны? Средства в плюсах давно есть. А если у тебя генетическая склонность стрелять по своим ногам, то тут и раст не справится.
	Ответить | Правка | Наверх | Cообщить модератору

	255. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Герман (??), 15-Янв-24, 12:42
	Средства, использования которых необязательны? Было бы в плюсах все хорошо с безопасностью, не было бы придумано столь много безопасных замен ему. Раст учит разработчиков с самого начала изучения следить за правильной работой с памятью, не давая некорректному коду скомпилироваться Говорят, что у Раста мнимая безопасность, потому что есть unsafe (который в случае ошибки при работе с памятью, укажет разработчику, куда стоит смотреть в первую очередь), но код на плюсах - весь unsafe
	Ответить | Правка | Наверх | Cообщить модератору

	347. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (341), 15-Янв-24, 16:51
	> шаблоны. Чудовище Франкенштейна самое настоящее. В ядре такое - недопустимо Давайте полюбуемся на простые _Generic-макросы в ядре. И вообще на макросы. https://github.com/torvalds/linux/blob/052d534373b7ed33712a6... https://github.com/torvalds/linux/blob/052d534373b7ed33712a6...
	Ответить | Правка | К родителю #204 | Наверх | Cообщить модератору

	6. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (6), 14-Янв-24, 21:50
	А сколько там модулей в стандартной библиотеке, которые меняются из версии в версию (просто как вот это всё дебажить потом на уязвимости, если ядро на C уже вселенского масштаба)
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	7. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (7), 14-Янв-24, 21:50
	Даже в Gentoo завезли бинарное ядро.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	36. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (36), 14-Янв-24, 22:43
	Для истинных гентушков это ничкго не изменило.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (105), 15-Янв-24, 02:02
	Как будто только гента позволяет ядро пересобрать. В Void это делается ровно точно так же с конфигом ядра без всяких use флагов.
	Ответить | Правка | Наверх | Cообщить модератору

	452. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (452), 16-Янв-24, 00:06
	Так сборка ядра в Генте ничем не отличается от сборки в других Линуксах. Неиспользуются при этом флаги USE. Только вот линуксоиды ныне измельчали, не собирают себе ядра. А потом ноют, что им такое жирнючее положили в дистр.
	Ответить | Правка | Наверх | Cообщить модератору

	517. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 16-Янв-24, 13:49
	Отличается же, в генте не нужно готовить всякий шлак вроде initrd и не нужно собирать всё ядро. В других линуксах всё же обычно дают возможность пересобрать всё и это очень долго, а ксатомизировать крайне геморно
	Ответить | Правка | Наверх | Cообщить модератору

	601. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 17-Янв-24, 04:16
	> Отличается же, в генте не нужно готовить всякий шлак вроде initrd и > не нужно собирать всё ядро. В других линуксах всё же обычно > дают возможность пересобрать всё и это очень долго, Yolo! Я майнлайне кернель под дебианом собираю. В билдсистеме ядра даже есть генерация пакетов. Таргет "make bindeb-pkg" - и билдсистема сама скроит пакетик с кернелом в лучшем виде. И да, часть систем тоже взлетает без initrt. Хоть они и дебианы. Что в этом такого? И уж конечно кастомизировать можно все что угодно. Билдится это - в зависимости от того что включено. Только билдить кернел для 1 тазика не совсем практично - для какого-то "класса железок" намного прагматичнее. Ибо майнтайнить зоопарк - затея весьма голимая. Особенно как локалхостов становится более десятка. > а ксатомизировать крайне геморно Я бы не назвал menuconfig чем-то ужасным. А вон там для референса дистровский конфиг есть например. И гемор - он в чем? И чего так уж упрощает в этом гента? Там самое сложное - это понимать что эти галочки реально делают. Гента в этом не поможет вообще никак :)
	Ответить | Правка | Наверх | Cообщить модератору

	623. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (623), 17-Янв-24, 16:35
	>  А вон там для референса дистровский конфиг есть например. И гемор - он в чем? Тем, что этот конфиг слишком избыточный и проще начать всё делать с нуля. Сложность заключается в кол-ве телодвижений от начала процесса и до выкатки в бутовый конфиг за вычетом времени в menuconfig
	Ответить | Правка | Наверх | Cообщить модератору

	647. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 19-Янв-24, 18:46
	> Тем, что этот конфиг слишком избыточный и проще начать всё делать с нуля. ИМХО где как. На десктопе я от дистровского конифига танцевал, таргетируя более-менее похожие на мой компы x86-64, без совсем редких вундервафель махрового энтерпрайза или винтажного добра редко встречающегося в x86-64. Да, кернел жирнее и дольше билдится. Зато подымает 3 мои компа включая "альтернативные/бэкапные" и ноут. Без затрат времени на билдовку им уберкастома. Это осознанный tradeoff. А например на ARM - я местами и от мелкого defconfig оттанцевал. Потому что вот там из дистрокернела вырезать ненужное можно и заманаться уже, если я таргетирую допустим пяток похожих железок на чипах одной фирмы и более - нифига. > Сложность заключается в кол-ве телодвижений от начала процесса и до > выкатки в бутовый конфиг за вычетом времени в menuconfig Когда тазиков оказывается не 1 а эн, начинает хотеться некоторого обобщения оных и урезания объема работ. Если у меня легион одноплатников - и я буду каждому кернел под микроскопом пилять - я тогда займусь только микро-оптимизациями, а на более полезные и интересные проекты времени не останется. И вот интеерсные проекты будут спущены в угоду 2% перфоманса. А оно того точно стоило? Эти 2% никто не заметит - и я уж точно не упирался в 2% перфоманса в задачах которые там были. Иначе я бы выбрал более мощную железку, для более разумных сроков проекта.
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от maximnik0 (?), 14-Янв-24, 21:51
	>Нельзя туда цпп. Ладно модули, только не ядро. Запаримся пересобирать же! Си собирается намного шустрее. Так разговоры давно идут об введений подмножеств - урезанной современной версии языка.С выкидыванием всякого хлама,там такого всего накопилось ...... Вообще удивительно как это еще собирается.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	63. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 14-Янв-24, 23:43
	> Так разговоры давно идут об введений подмножеств - урезанной современной версии языка. > С выкидыванием всякого хлама,там такого всего накопилось ...... Так то g++ заметно тормознее gcc... потому что C++ куда как более фичастый язык. И время жевания сорцов на плсоте - ну вот реально заметно дольше. Хоть там как.
	Ответить | Правка | Наверх | Cообщить модератору

	458. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (452), 16-Янв-24, 00:13
	И чё? Когда сам GCC c версии 4.8 тоже начал постепенный переход на C++, тоже ныли, мееедленно. Вот спустя десяток лет, полёт нормальный. Пользуемся и не замечаем. Уж некоторые и забыли/не знали, что он на C++.
	Ответить | Правка | Наверх | Cообщить модератору

	475. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 16-Янв-24, 02:52
	> И чё? Когда сам GCC c версии 4.8 тоже начал постепенный переход > на C++, тоже ныли, мееедленно. Вот спустя десяток лет, полёт нормальный. > Пользуемся и не замечаем. Уж некоторые и забыли/не знали, что он на C++. А вы часто вот именно gcc сами компилите, чтобы разницу в времени компила gcc ощутить? Так то его заметно тормознее себе перекомпиливать стало. Я это еще и практикую, так что знаю о чем говорю. На скорость работы скомпиленой прогрыммы это может и не влиять. А вот на скорость компила очень даже. Ну и вот проги на плюсах - заметно дольше компилятся "при прочих равных" (e.g. примрено одинаковая функциональность).
	Ответить | Правка | Наверх | Cообщить модератору

	583. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 16-Янв-24, 21:47
	> Так то g++ заметно тормознее gcc...   Это в прошлом было такое. А сейчас что скорость компиляции примерно одинакова, с очень небольшим преимуществом gcc, в среднем, но не всегда.   Но нет дыма без огня. В разных сборках компиляторов скорость может отличаться в разы, например, бывает "хорошая" сборка g++ может быть заметно быстрее gcc или другой сборки g++. Такой бардак с компиляторами есть для esp32 и stm32, и вляпавшись в крайние отклонения в скорости компиляции "удачной" пары компиляторов можно сделать неверные выводы.   При тесте на исходнике который могут переварить оба компилятора, нормальных сборок, то разница незначительна, и быстрее может оказаться и g++.   А  если понаворотите кода, то логично, что работы станет больше, и оптимизировать тоже  надо.   А еще некорректно сравнивать скорость компиляции в отрыве от результата компиляции, а то clang часто быстрее g++, но у g++ бинарник получше на мой взгляд выходит.
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	603. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 17-Янв-24, 04:30
	> А сейчас что скорость компиляции примерно одинакова, с очень небольшим преимуществом 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ообщить модератору

	615. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 17-Янв-24, 12:26
	>>А зачем мне васянские сборки, опять же? Если например пересборка компилятора esp32s3 и системы сборки сократила время сборки проекта  с 40 до 8 секунд, то таких Васянов на руках носить надо. Впрочем, раз Вы вполне опытный, можете собрать и сами. А если "Васяны" дали подсказку куда копать, то и их труды не пропали. >>куда скромнее по скорости сборки, при том что в общем то тесты довольно примитивны Малый разрыв в скорости, это когда си-исходник собирается с++ компилятором. Но это справедливо для одной версии и сборки компиляторов clang и gcc. А разные версии и сбоки могут отличаться как угодно Ещё на слабых для разработки компах, и тем более каких есть ноутбуках, свежие компиляторы в принципе медленнее старых версий их же самих. И разрыв между компиляцией си и с++ будет вполне заметен. А на среднемощном десктопе таки пофиг.
	Ответить | Правка | Наверх | Cообщить модератору

	673. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 21-Янв-24, 16:53
	> Впрочем, раз Вы вполне опытный, можете собрать и сами. А если "Васяны" > дали подсказку куда копать, то и их труды не пропали. Я ESP не использую, и врядли буду когда либо. Так что это знание может и будет полезно... но кому-то другому. > Малый разрыв в скорости, это когда си-исходник собирается с++ компилятором. Вы издеваетесь? Меня жонглирование цифрами не интересует, интересно время фактической сборки проектов. Зачем мне обманывать самого себя? И в этом смысле плюсовые проекты заметно тормознее билдить. > Ещё на слабых для разработки компах, и тем более каких есть ноутбуках, > свежие компиляторы в принципе медленнее старых версий их же самих. И > разрыв между компиляцией си и с++ будет вполне заметен. А на > среднемощном десктопе таки пофиг. У меня довольно мощный десктоп - и - боюсь я очень даже вижу разницу в времени билда старого gcc и нового где плюсоту можно стало, например. А по сравнению с кернелом gcc так то довольно небольшой проект. Заякорить билд кернела в пару раз было бы очень такой себе идеей. На разлапистой конфиге там и так время билда очень даже.
	Ответить | Правка | Наверх | Cообщить модератору

	674. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 21-Янв-24, 19:21
	Как нас унесло. Изначальный смысл был скормить си исходники компилятору с++, а не переписывать, чем занята другая группа. Мощные десктопы на работе, и дома у любителей. У меня тоже есть и мощные. Но случаи бывают разные. Банально что то поправить, и собрать не дома. Есть ещё командировки. И студенты в конце концов. >>плюсовые проекты заметно тормознее билдить. Плюсовые, да, там же тупо язык сложнее. Но не такая редкость когда по сути си проекты, с минимумом фич от с++, или их отсутствием, собирают с++ компилятором. И тут, взависимости от стиля исходника, бинарник может получиться и лучше, и контроль типов получше, а разница во времени компиляции минимальна в подобных случаях. Вообще, если не рассматривать ядро, то гораздо чаще сборку проекта можно ускорить не заменой компилятора, а его реорганизацией проекта, зависимостей, и правилами сборки, а то именно на мощных компах проекты "начинающих" и "консерваторов" не используют все ресурсы компа, и даже на мощной машине собираются неспешно.
	Ответить | Правка | Наверх | Cообщить модератору

	675. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 21-Янв-24, 20:34
	> Как нас унесло. Изначальный смысл был скормить си исходники компилятору с++, а > не переписывать, чем занята другая группа. Вот те раз. А я то думал изначальный смысл - оценить технологию, по возможности объективно и непредвзято. И в этом смысле меня таки как кастомщика и кернелбилдера в контексте сабжа беспокоит потенциал для обвала скорости компила в разы. Да, C++ позволяет более выразительные конструкции. Если б еще наслоения легаси выкинуть, и оформить более безопасный subset дефолтов "для чайников" - был бы наверное неплохой яп так то. Но в случае с проектом размером с кернел есть много разных аспектов. Время компила напрямую влияет на допустим степень протестированности кода, да и скорость разработки якорит. Не, коду который "haven't seen compiler" я не доверяю. Never had, and never will. > Мощные десктопы на работе, и дома у любителей. У меня тоже есть и мощные. Времена билда кернела могут напрячь и на таких. Помножить эти времена на эн - очень так себе идея. К тому же это все создает entry level barrier там где его быть не должно, отсеивая всяких студентов и ко. Зачем нам это проект без студентов и энтузиастов, где только мегакорпы? > Но случаи бывают разные. Банально что то поправить, и собрать не дома. > Есть ещё командировки. И студенты в конце концов. Ну дык. Чем злее требования к конфиге - тем меньше народа это все будет делать. Это идет вразрез с идеями опенсорса - и куда это заведет? К тому что пилить будут полтора корпората с билдфермами? Так что совсем игнорить этот топик имхо не стоит. >>>плюсовые проекты заметно тормознее билдить. > Плюсовые, да, там же тупо язык сложнее. Но не такая редкость когда > по сути си проекты, с минимумом фич от с++, или их > отсутствием, собирают с++ компилятором. Это в основном майкрософтовские кодеры таким страдают, как и юзежом си++ в режиме "чуть улучшеный си". Вызвано убогостью MSVS как си компилера, но в случае сабжа не аргумент ибо - unsupported config. > И тут, взависимости от стиля исходника, бинарник может получиться и лучше, С фига ли вдруг? > и контроль типов получше, Да вообще-то в сях он весьма даже. А если кто думал что знает о типах все, пусть попробует -Wconversion поюзать. И таки - компилер то может. А вот сможете ли вы с этим жить, если вам на pre-existing проекты вот такие жесткие проверки влепить... > Вообще, если не рассматривать ядро, то гораздо чаще сборку проекта можно ускорить > не заменой компилятора, а его реорганизацией проекта, зависимостей, и правилами сборки, Ну да, давайте искать не там где ключ потеряли, а под фонарем, потому что там светло. Вон то все же похоже на костыль или неизбежное зло, которым занялись от отличной скорости сборки плюсоты. Это конечно не оправдание для совсем уж хреновых подходов. > а то именно на мощных компах проекты "начинающих" и "консерваторов" не > используют все ресурсы компа, и даже на мощной машине собираются неспешно. Да вообще-то при пинке в кучу потоков процы оно нормально жрет и как раз упирается в именно проц. Вот особенно - плюсота как раз. Там именно g++ плотно проц грузит надолго, в остальное захочешь не упрешься. На сях там еще может быть всякий оверхед, io и проч, т.к. относительно резво билдует. Но в плюсах это как раз намного меньшая проблема.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+4 +/–
	Сообщение от Аноним (20), 14-Янв-24, 22:12
	А зачем вы его постоянно пересобираете?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	40. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
	Сообщение от Аноним (36), 14-Янв-24, 22:46
	2.6.32 работает - не трожь!
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от anonymous (??), 14-Янв-24, 23:39
	Потому что оно багованное. Проверяем, есть ли баги в новых версиях.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	104. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (20), 15-Янв-24, 01:49
	Так это ж надо желать один раз, когда хочется попробовать новую версию. А один раз - какая разница, сколько оно собирается? Это ж не 200 тысяч запросов в секунду где время обработки имеет значение.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (77), 15-Янв-24, 00:06
	> А зачем вы его постоянно пересобираете? Потому что его постоянно правят. Вот бы заморозили его разработку, да? Тогда можно было бы переписывать на любые языки и не заботиться о том, что кто-то захочет его собрать.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	277. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от pv (?), 15-Янв-24, 13:23
	> А зачем вы его постоянно пересобираете? https://bellard.org/tcc/tccboot.html а ведь когда-то можно было и так, игрушечным компилятором размером в 100кБ, написанным изначально вообще для ioccc. да и чего мелочиться, в ядре просто необходим питон, яваскрипт, го, и вижуалбэйсик! и систему сборки ещё обязательно поменять, а то несовременно как-то.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	27. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (27), 14-Янв-24, 22:27
	опять огульные выдуми кро скорость сборки. когда же вы успокоитесь, выдумщики
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	34. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (36), 14-Янв-24, 22:40
	>Запаримся пересобирать же! Си собирается намного шустрее. А что вы про Rust запоёте?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	179. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Проходил мимо (?), 15-Янв-24, 08:00
	Судя по комментариям, большинство из тех, кто "поет" на OpenNET про Rust разбираются в нем примерно как свинья в апельсинах. Хотя, возможно, свинья разбирается все же лучше. Хейтеры, которые ниАсилили. Естественно, что у любого, кто в теме вопли всяких криворуких рукожопов вызывают лишь гомерический смех. PS Это не значит, что Rust идеальный и у него нет проблем. Некоторые вещи там сделаны не лучшим образом.
	Ответить | Правка | Наверх | Cообщить модератору

3. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–11 +/–
Сообщение от Аноним (3), 14-Янв-24, 21:46
> В списке рассылки Шёл 2024 год...
Ответить | Правка | Наверх | Cообщить модератору

	5. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–5 +/–
	Сообщение от Аноним (3), 14-Янв-24, 21:47
	П.с. Так там ещё и 80 символов ограничение 🤦‍♀️
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+5 +/–
	Сообщение от Аноним (9), 14-Янв-24, 21:53
	> checkpatch/coding-style: deprecate 80-column warning https://lkml.org/lkml/2020/5/31/326
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–3 +/–
	Сообщение от Аноним (115), 14-Янв-24, 23:57
	Отличное ограничение, ещё бы TABы сделали равными 4м символам или вообще заменяли бы их на пробелы
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	118. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (107), 15-Янв-24, 02:37
	А лучше трем символам. Или может восьми, видел и такое.
	Ответить | Правка | Наверх | Cообщить модератору

	296. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (296), 15-Янв-24, 14:03
	В ядре как раз-таки 8
	Ответить | Правка | Наверх | Cообщить модератору

	451. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от InuYasha (??), 16-Янв-24, 00:04
	*стирает исходники ядра пры..линукса* фу.
	Ответить | Правка | Наверх | Cообщить модератору

	313. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (313), 15-Янв-24, 14:58
	Яваскриптеры голосуют за два пробела. В общем, после окончания споров "табы/пробелы" появляется множество других интересных и продуктивных споров на тему того, сколько именно пробелов использовать. Таким образом, находится и работа для тех, кому код писать не получается, а поучаствовать в разработке охота.
	Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

	291. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (293), 15-Янв-24, 13:49
	Лучше пробелы, тогда форматирование не зависит от настроек редактора кода и, следовательно, не едет.
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	304. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от rmh (?), 15-Янв-24, 14:34
	>Лучше пробелы Не лучше. Таб = 1 байт, пробелы >1 байта.
	Ответить | Правка | Наверх | Cообщить модератору

	521. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 16-Янв-24, 14:11
	> Не лучше. Таб = 1 байт, пробелы >1 байта. И что?
	Ответить | Правка | Наверх | Cообщить модератору

	311. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–2 +/–
	Сообщение от Аноним (313), 15-Янв-24, 14:52
	> не зависит от настроек редактора кода и, следовательно, не едет. Ложь. Едет, если в редакторе настроена замена пробелов табуляциями. То есть от настроек редактора зависит.
	Ответить | Правка | К родителю #291 | Наверх | Cообщить модератору

	391. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (391), 15-Янв-24, 19:14
	едет, если умственно-ограниченные начинают использовать табуляцию не для индентификации кода (и использовать этот символ строго в начале строки до первого не-пробельного), но и пытаются табуляцией что-то форматировать в середине строки.
	Ответить | Правка | Наверх | Cообщить модератору

	420. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (313), 15-Янв-24, 21:29
	Фанаты пробелов - это потомки тех, кто в 90-х в офисе вместо настройки первой строки абзаца отбивали этот отступ пробелами.
	Ответить | Правка | Наверх | Cообщить модератору

	315. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (313), 15-Янв-24, 15:01
	Вы бредите. Табуляция - это табуляция, ОДИН символ. Что значит "равной 4 символам"?
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	321. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (115), 15-Янв-24, 15:17
	TAB это терминальный опкод, а не символ. Ровно как и все ASCII символы до 0x20 не символы.
	Ответить | Правка | Наверх | Cообщить модератору

	376. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от VladSh (?), 15-Янв-24, 18:50
	Ну пусть будет 1 оп. код вместо четырёх; есть же разница?
	Ответить | Правка | Наверх | Cообщить модератору

	453. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от InuYasha (??), 16-Янв-24, 00:07
	когда я в подном большом проекте заменил все отступы на табы (вместо 4 пробелов) и \r\n на \n, сэкономилось несколько МАГАБАЙТ. И это всё каждый раз парсилось ИДЕ, компилятором, гитом, архиватором...
	Ответить | Правка | Наверх | Cообщить модератору

	477. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 16-Янв-24, 02:55
	> когда я в подном большом проекте заменил все отступы на табы (вместо > 4 пробелов) и \r\n на \n, сэкономилось несколько МАГАБАЙТ. И это > всё каждый раз парсилось ИДЕ, компилятором, гитом, архиватором... А еще на несколько мегов меньше читать и парсить (компилеру whitespaces до лампочки, это ж не питон). Тоже так то аргумент.
	Ответить | Правка | Наверх | Cообщить модератору

	482. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (482), 16-Янв-24, 06:37
	Производительность взлетела до небес, наверное.
	Ответить | Правка | К родителю #453 | Наверх | Cообщить модератору

	520. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 16-Янв-24, 13:53
	Что такой тугой, TAB равен изначально 8-и символам и это неудобно. Что породило со временем кастомные настройки размера TAB-ов, например, более практичный 4 символа. И по факту теперь это плаваяющая единица из-за чего при разных настройках едет форматирование текста. Потому TAB в современном мире непригоден для использования. Ситуацию можно починить если вхерачить в UTF специальные коды для TAB-ов разного размера или же инструкцию с заданием длины TAB-ов.
	Ответить | Правка | К родителю #376 | Наверх | Cообщить модератору

	531. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (525), 16-Янв-24, 14:56
	Ещё раз, специально для вас. Форматирование при использовании табов едет только у тех, кто между табом и пробелом выбирает, бросая игральные кости. У тех, кто использует табы только для отступов, ничего не едет, а изменение размера табуляции позволяет сделать код более читабельным: кому-то комфортнее 8 столбцов в отступе, кому-то 2.
	Ответить | Правка | Наверх | Cообщить модератору

	565. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 16-Янв-24, 17:52
	Какой и ты тугой. Форматирование в общем случае едет всё равно потому что TABы конкурируют с обычным текстом в соседних строках. Например, это разбивка длинных аргументов у функций на строки, это многострочные комментарии с развёрнутыми пояснениями, это идиотский GNU стиль расстановки скобочек {. И многое другое. > а изменение размера табуляции позволяет сделать код более читабельным: кому-то комфортнее 8 столбцов в отступе, кому-то 2. Галиматью несёшь. Код сразу форматируется под конкретный размер TABа и с другими размерами форматирование едет
	Ответить | Правка | Наверх | Cообщить модератору

	566. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 16-Янв-24, 17:55
	Типичный, кстати, пример, где всё это едет, как раз линуксовое ядро, которое пишется под стандартный TAB
	Ответить | Правка | Наверх | Cообщить модератору

	584. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 16-Янв-24, 22:00
	> ТAB равен изначально 8-и символам Даже на печатных машинках Табы настраивались на любые позиции, не обязательно с шагом, а именно произвольно. Бардак был изначально, но на бумаге выходили пробелы.
	Ответить | Правка | К родителю #520 | Наверх | Cообщить модератору

	676. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Капитан О. (?), 21-Янв-24, 20:37
	> Даже на печатных машинках Табы настраивались на любые позиции, не обязательно с > шагом, а именно произвольно. > Бардак был изначально, но на бумаге выходили пробелы. На печатных машинках чужие исходники не отображали так что там проблема с тем что форматирование не то как задумано и не возникала...
	Ответить | Правка | Наверх | Cообщить модератору

	681. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 22-Янв-24, 18:23
	TAB - был не символом, а кодом движения печатающей головки или руки оператора. Поэтому и проблем не возникало, потому что на экране или бумаге был текст с пробелами. А использовать TAB как символ в исходниках было ошибкой.
	Ответить | Правка | Наверх | Cообщить модератору

	10. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от nich (ok), 14-Янв-24, 21:58
	Да вообще тупые.  Пора уже на слак перейти, или накрайняк на дискорд.  Я уже устал читать их многостраничные сообщения в рассылке.  В слаке или в дискорде каждое сообщение будет не более двух-трех строчек.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	137. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+4 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 03:14
	Лучше в твиттер (или как она там называется теперь)
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (16), 14-Янв-24, 22:05
	... и до сих пор не придумали ничего лучше, чем форум. Даже в виде рассылки.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	109. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+4 +/–
	Сообщение от Аноним (107), 15-Янв-24, 02:12
	Подозревая, что в 2044 половина модных сервисов позакрывается, а списки рассылки и их архивы будут на месте.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	160. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Тот_Самый_Анонимус_ (?), 15-Янв-24, 05:36
	>Шёл 2024 год... О, кто-то календарь перевернул!
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

11. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
Сообщение от Аноним (11), 14-Янв-24, 21:59
> "Now, "why not Rust"? First of all, Rust uses a different (often, in my opinion, gratuitously so) syntax Это он ещё очень дипломатично выразился относительно этого нагромождения сокращений и спецсимволов.
Ответить | Правка | Наверх | Cообщить модератору

	81. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–5 +/–
	Сообщение от Аноним (81), 15-Янв-24, 00:13
	А какая тебе разница, какие там спецсимволы? Тебе алгоритмы писать, а не буковки разглядывать. Так что пофиг какой в языке синтаксис, это вопрос десятый. Если уж так хочется - можно и DSL написать с другим синтаксисом.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+8 +/–
	Сообщение от Витюшка (?), 15-Янв-24, 01:35
	Синтаксис очень очень важен именно для алгоритмов, сложного нетривиального кода. Код должен ясно передавать намерения (высокоуровневые) и идеи алгоритма. Это как раз для передачи json по http синтаксис не столь важен, "можно потерпеть", не критично. Попробуй разобрать алгоритм на brainfuck.
	Ответить | Правка | Наверх | Cообщить модератору

	573. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (573), 16-Янв-24, 18:57
	> Код должен ясно передавать намерения (высокоуровневые) и идеи алгоритма. Нет. Код должен реализовывать алгоритм, который описан обычным человеческим языком в комментарии прямо перед ним, а реализация должна быть обязательно аннотирована ссылками на это описание и, по необходимости, прокомментирована. В случаях когда реализация использует оптимизации (например, специфические для ЯП или аппаратной платформы), они обязательно должны быть прокомментированы с описанием оснований для принятия решения об оптимизации, списком рассмотренных альтернатив, результатами бенчмарков и снабжены тестами, эти самые бенчмарки реализующими. В противном случае действительно можно и на brainfuck писать с тем же успехом.
	Ответить | Правка | Наверх | Cообщить модератору

	575. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 16-Янв-24, 19:09
	>> Код должен ясно передавать намерения (высокоуровневые) и идеи алгоритма. > Нет. Код должен реализовывать алгоритм, который описан обычным человеческим языком в комментарии > прямо перед ним, а реализация должна быть обязательно аннотирована ссылками на > это описание и, по необходимости, прокомментирована. В случаях когда реализация использует > оптимизации (например, специфические для ЯП или аппаратной платформы), они обязательно > должны быть прокомментированы с описанием оснований для принятия решения об оптимизации, > списком рассмотренных альтернатив, результатами бенчмарков и снабжены тестами, эти самые > бенчмарки реализующими. В противном случае действительно можно и на brainfuck писать > с тем же успехом. Это верно, но есть нюанс. Идея "самодокументированного кода" позволяет автору сохранить хоть какой-то контроль за проектом. Что важно, когда он лишается имущественных прав по лицензиям типа GPL. Потому имеем, что имеем.
	Ответить | Правка | Наверх | Cообщить модератору

	648. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 19-Янв-24, 18:50
	> Это верно, но есть нюанс. Идея "самодокументированного кода" позволяет автору сохранить > хоть какой-то контроль за проектом. Что важно, когда он лишается имущественных > прав по лицензиям типа GPL. Потому имеем, что имеем. В каком месте GPL лишает кого-то имущественных прав? Цитату?
	Ответить | Правка | Наверх | Cообщить модератору

	659. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 20-Янв-24, 08:36
	>> Это верно, но есть нюанс. Идея "самодокументированного кода" позволяет автору сохранить >> хоть какой-то контроль за проектом. Что важно, когда он лишается имущественных >> прав по лицензиям типа GPL. Потому имеем, что имеем. > В каком месте GPL лишает кого-то имущественных прав? В месте замены "право" на "лево". > Цитату? "copyleft"
	Ответить | Правка | Наверх | Cообщить модератору

	661. Скрыто модератором	+/–
	Сообщение от Аноним (-), 20-Янв-24, 11:26
	> В месте замены "право" на "лево". >> Цитату? > "copyleft" И где тут акт отчуждения прав происходит?
	Ответить | Правка | Наверх | Cообщить модератору

	669. Скрыто модератором	+/–
	Сообщение от n00by (ok), 20-Янв-24, 15:36
	>> В месте замены "право" на "лево". >>> Цитату? >> "copyleft" > И где тут акт отчуждения прав происходит? Наймите юриста, пусть он и разъясняет в подробностях, что такое copyright, и что такое copyleft. Мне в принципе не интересен данный разговор с тем, кто не может заявить "вот, смотрите, я создал проект под GPL", потому что такой -- материально заинтересованное лицо, не являющееся автором.
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
	Сообщение от Аноним (170), 15-Янв-24, 07:22
	Код гораздо чаше нужно читать, чем писать. Поэтому, чем удобнее его читать, тем лучше. Си в этом плане кстати тоже не идеал, но определённо лучше Rust и C++.
	Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

	197. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Советский инженер (ok), 15-Янв-24, 09:55
	>... но определённо лучше Rust и C++ с этим тоже можно поспорить, т.к. на читиаемость влияет и количество строк и goto всякие.
	Ответить | Правка | Наверх | Cообщить модератору

	582. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от adolfus (ok), 16-Янв-24, 20:33
	В С++ есть большая проблема -- ссылки в перечне параметров функции. Это препятствует использованию там r-value. А как известно, любое l-value в программе добавляет +1 к пулу потенциальных проблем безопасности и программных ошибок. Что касается goto, то без него вы даже из вложенного цикла не выйдете. Вернее, выйдете, но через виртожопу.
	Ответить | Правка | Наверх | Cообщить модератору

	609. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (609), 17-Янв-24, 08:27
	>Что касается goto, то без него вы даже из вложенного цикла не выйдете. Что касается "обычных непричин", нон-секвитуров и прочих нерелевантных доводов, выходы из вложенных циклов просто свидетельство каши в коде и в голове разраба. >Вернее, выйдете, но через виртожопу. Из через жопу написанного кода любой выход только такой. И с помощью goto в первую очередь.
	Ответить | Правка | Наверх | Cообщить модератору

	614. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от adolfus (ok), 17-Янв-24, 12:04
	Ну так пройдитесь просто по двумерному массиву. Когда-нибудь изображения обрабатывали? А гиперспектральные, которые трехмерные массивы? Парсер простой напишите без goto для какого-нибудь примитивного языка, например, для джейсона. Все без исключения FSM-алгоритмы, коими и являются эти самые синтаксические анализаторы, работают на goto безальтернативно.
	Ответить | Правка | Наверх | Cообщить модератору

	610. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (609), 17-Янв-24, 08:32
	>Что касается goto, то без него вы даже из вложенного цикла не выйдете. "Cache-friendly программирование? Не, не слышали." И продолжили выходить из вложенных циклов... А главное, писать вложенные циклы.
	Ответить | Правка | К родителю #582 | Наверх | Cообщить модератору

	616. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от adolfus (ok), 17-Янв-24, 12:34
	>>Что касается goto, то без него вы даже из вложенного цикла не выйдете. > "Cache-friendly программирование? Не, не слышали." И продолжили выходить из вложенных > циклов... А главное, писать вложенные циклы. "Каше-френдли" программирование начинается прежде всего с безальтернативного использования статических библиотек вместо динамических и минимизации длинных переходов. Причем прежде всего это касается вызовов процедур, поскольку каждый call сопровождается еще и ret'ом. Итого два сброса всех кешей кода в одном вызове. А короткие переходы, которые в основном и генерируются из goto, кеши кода не портят, поскольку все это происходит в пределах одной страницы. Причем и кеши данных не сбрасывают тоже, поскольку к памяти данных/стека, в отличие от call/ret не обращаются. Кстати, обращение к любой функции в .so несколько раз сбрасывает все кеши, что есть. Сначала дальняя ссылка на GPT, потом дальний переход на процедуру и потом возврат из дальнего вызова. Есть несколько постулатов, используемых, в том числе, и в программировании, следование которым позволяет серьезно повысить качество программ. Это: 1) явное всегда лучше неявного; 2) административные проблемы плохо решаются техническими средствами, а технические -- административными, поэтому "Каждому свое", как было написано на воротах одного гуманитарного заведения. Эти два пункта относятся прежде всего к стилям програмирования, в том числе и к goto. Смысл состоит в том, что проблемы, проистекающие из-за хреновых навыков программирования (это всегда у нас и у них тоже называлось "логические ошибки"), невозможно адекватно решать с помощью каких-то особых и "безопасных" языков программирования. Все эти якобы "безопасные" парадигмы и языки поголовно работают поверх кода, написанного на сях, да и сами в 99% случаях написаны на них же, представляя просто фреймворк. Питон, например, один из них. Второй момент -- их использование не дает прграммисту расти. Он просто скачет от одной "технологии" к другой, оставаясь на уровне своего лучшего курсового проекта. Умение работать с памятью приходит только с опытом работы с ней и никак не иначе.
	Ответить | Правка | Наверх | Cообщить модератору

	622. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 17-Янв-24, 14:45
	Предсказание и предвыборка команд работают для call/ret начиная с NetBurst (и для far call/ret работают, но эти команды не используются в плоской модели памяти). Но это не повод отказываться от статического связывания. Calls and returns are expensive; use inlining for the following reasons: • Parameter passing overhead can be eliminated. • A mispredicted branch can lead to performance penalties inside a small function that are larger than those that would occur if that function is inlined. • In a compiler, inlining a function exposes more opportunity for optimization. • If the inlined routine contains branches, the additional context of the caller may improve branch prediction within the routine.
	Ответить | Правка | Наверх | Cообщить модератору

	397. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от warlock66613 (ok), 15-Янв-24, 19:53
	И Rust и C++ более выразительные языки чем C, и именно поэтому код на них гораздо проще читать.
	Ответить | Правка | К родителю #170 | Наверх | Cообщить модератору

	585. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 16-Янв-24, 22:07
	Оба языка позволяют как написать очень выразительно, так и нечитаемо, или понимаемо, но не так. ;) То есть, в плане оформления исходника, позволяют "прострелить себе ногу".
	Ответить | Правка | Наверх | Cообщить модератору

	635. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от wyry (?), 18-Янв-24, 18:20
	Несмотря на то, что я топлю за C++, не могу не придраться, что C++ ОЧЕНЬ опасен в плохих руках и там легко допустить плохие решения (как по семантике, так и по читаемости кода). Но преимущество C++ в том (и об этом говорили многие задолго до китов), что C++ напрямую связан с C и всё можно переписывать плавно не боясь что-то сломать.
	Ответить | Правка | К родителю #397 | Наверх | Cообщить модератору

	490. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от scriptkiddis (?), 16-Янв-24, 10:01
	Ну и че ты не переписал еще все ядро на brainfuck?
	Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

	248. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+4 +/–
	Сообщение от Аноним (248), 15-Янв-24, 11:47
	Так сокращения это норма для линукса. cp, mv, dd, rm, ls, df, du, pz
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	258. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (258), 15-Янв-24, 12:45
	Это объясняется легаси.
	Ответить | Правка | Наверх | Cообщить модератору

	316. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (313), 15-Янв-24, 15:05
	Могу назвать ещё минимум две причины, по которым ls -l Лучше, чем list-files-and-directories --show-as-much-details-as-possible
	Ответить | Правка | Наверх | Cообщить модератору

	382. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (-), 15-Янв-24, 18:59
	> Могу назвать ещё минимум две причины, по которым > ls -l > Лучше, чем > list-files-and-directories --show-as-much-details-as-possible Вы только что рассказали почему powershell - ацтой каких мало. Ах да, автодополнение в том уродце не работает по сути никак, чтобы вы уж точно сломали пальцы. Как-то так и понимаешь где индусы, а где гении.
	Ответить | Правка | Наверх | Cообщить модератору

	393. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (341), 15-Янв-24, 19:24
	Наоборот же, 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ообщить модератору

	446. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (446), 15-Янв-24, 23:57
	> Наоборот же, powershell показывает, что можно всем угодить > изкоробочными алиасами и parameter name matching'ом Он мне так угАдил своим синтаксисом, километровыми командами и очешуенным временем старта на виртуалках что я как раз и развидел маздайку к хренам. И назад уже никогда не вернусь, хоть там что. Простите но какую задачу решает (ba)sh я понимаю. Какую задачу решает это индусское месиво я не понимаю. Мне такой шелл - без надобности. Совсем. Одно это уже бьет наповал ваше "всем"  наличием конкретного контрпримера. Не, я в принципе не собираюсь столько на клаве печатать в шелле. А когда там еще и автодополнение такое как там, пути с пробелами, и брейнфак с типизацией (в шелле!!!) - ну, знаете, вот пусть авторы этого и пользуются им.
	Ответить | Правка | Наверх | Cообщить модератору

	476. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (341), 16-Янв-24, 02:54
	> Какую задачу решает это индусское месиво я не понимаю. > брейнфак с типизацией (в шелле!!!) Ну жирноват-тяжеловат он, но вот идея типизированного шелла должна быть понятна. Должно быть понятно, зачем линуксоиды делают свой powershell в виде nushell.
	Ответить | Правка | Наверх | Cообщить модератору

	479. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 16-Янв-24, 03:04
	> Ну жирноват-тяжеловат он, но вот идея типизированного шелла должна быть понятна. Должно > быть понятно, зачем линуксоиды делают свой powershell в виде nushell. В результате самое крутое что есть в шелле ака мелкая автоматизация системной рутины по месту - здесь и сейчас - там по сути и невозможна. Эффективного интерфейса к системе - нет. Печатать километровые команды и параметры, с почти неработающим автодополнением, а вишенкой на торте еще и пути с пробелами и проч везде (хотели же длинно и интуитивно?) - это здорово, конечно, только в результате я то же самое в лине раз в 5 быстрее делаю. А если еще типизация начнет делать мозг... эээ... ну в общем сделать пайплайн там чаще всего не получается. А если я хотел похардкорить с мощным программизмом - не совсем понятно зачем это в вот именно шелле делать. Оно ж не ide, и с автодополнением джеппа.
	Ответить | Правка | Наверх | Cообщить модератору

	546. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (546), 16-Янв-24, 15:53
	Тебя опять что-ли шиза долбает, 294й? То что по умолчанию идёт с PSReadLine ты оппрыгаешься с башем. Алиасы давно по умолчанию сделаны и выглядят практически как в баш. Если ты в пайплайны не умеешь в ps - иди в дворники. А ещё, для автоматизации быстрой, жду аналог PowerCLI для vmware. Ты же в 5 раз быстрее сделаешь в лине. Покажи примеры.
	Ответить | Правка | Наверх | Cообщить модератору

	649. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 19-Янв-24, 19:03
	> Тебя опять что-ли шиза долбает, 294й? То что по умолчанию идёт с > PSReadLine ты оппрыгаешься с башем. Ну во первых я вобью проблему в поискарь и скопипащу 90% решения. Во вторых я не собираюсь бузинесс-логику или что там еще на шелле бжад наворачивать. Поэтому в 95% случаев мне вон то просто не приболело, а вот минусы - икнутся. > Алиасы давно по умолчанию сделаны и выглядят практически как в баш. А внутрях все равно летающий спагетти монстр с километрами макарон, норовящий типизацией куснуть и чего там еще. И время старта этой байды такое, что у меня в ряди случаев скрипты отработают быстрее чем ЭТО вообще только стартануть расчехлится на VM. Ну я и не понял зачем мне такой шелл надо, не разгоняет мою эффетивность и создает больше проблем чем решает. Не, я не хотел хардкорить в шелле. Для этого другие яп есть. > Если ты в пайплайны не умеешь в ps - иди в дворники. Я пошел в пингвина вместо этого - там с пайплайнами ноу проблем, и вообще, все как-то сильно проще и ненапряжнее. Можно сделать что хотел а не пытаться косплеить лучшие практики мега-иде зачем-то бжаж в шелле, где для этого инструментации нет. > А ещё, для автоматизации быстрой, жду аналог PowerCLI для vmware. Ты же > в 5 раз быстрее сделаешь в лине. Покажи примеры. Ну так я себе ряд операций с виртуалками прекрасно оптимизнул. Конечно для KVM и QEMU, нахрен мне вмварь? Более того - я себе _генерацию_ дебутстрапом наваял - с моими кастомизациями. У вас там уровень сцаного эксплуатанта. А я кастомдев, мне больше надо. На баше я это забацал минут за 10. А на этой повар-щели я бы часами долбался с тем же самым, воюя с не теми типами данных мля, и чем там еще. Оно мне надо?! А, да, ваш коллега пох (или нах?) таки - вот - плакался что вмварь сожрали. Вас ждут интересные времена! И хорошо что все это - не у меня :)
	Ответить | Правка | Наверх | Cообщить модератору

	684. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (684), 23-Янв-24, 19:00
	> Ну во первых я вобью проблему в поискарь и скопипащу 90% решения. У тебя как 294й, с способностью понимать тексты? Проблема? Скопипасть в поискарь и найди что делает PSReadLine, потом рассказывай как в баш это круто. > Во вторых я не собираюсь бузинесс-логику или что там еще на шелле бжад наворачивать. Поэтому в 95% случаев мне вон то просто не приболело, а вот минусы - икнутся. О, опять очередной передерг. Аж два сразу. Во первых бизнес-логика. Про неё тут никто и не говорил. Во вторых примудил мифические минусы. Которые кроме тебя никто не наблюдает. > А внутрях все равно летающий спагетти монстр с километрами макарон, норовящий типизацией куснуть и чего там еще. И время старта этой байды такое, что у меня в ряди случаев скрипты отработают быстрее чем ЭТО вообще только стартануть расчехлится на VM. Это любители башпорятнок рассказывают? Ну те что в соседних треда точно такой же аргумент приводят на тему системд и другой системы инициализации. Только там лапша в баше у них. Ты про алиас то в поисковик можешь вбить болезный? Ну и показать насколько букв команда в баше cd больше цмдлета в пауршеле cd? Хотя у кого хаотическое мышление им действительно не понять - как это правила именования команд сделать и их соблюдать. А поверх сделать просто алиасы. Ну про телегу разных шелов и разное поведение в разных ОС вообще промолчу. Переносимость это не про тебя. Как же ты лохов обувать будешь, если подпиливать твои портянки не надо будет под каждый чих. Проще в несколько команд прогнать объект и вытащить нужный процесс по тому же показателю памяти. Чем писать десятки строк под каждую ОС и шел. Мне своё время дороже. Но твоё ничего не стоит, поэтому пиши партянки с макаронинами под мак-вин-лин и разные шелы. > Я пошел в пингвина вместо этого - там с пайплайнами ноу проблем, и вообще, все как-то сильно проще и ненапряжнее. Ну так все и поняли что ты не умеешь в пайплайны. Сейчас в куче мест ушли все в курьеры. Мест для дворников полно. Сходи - пособеседуйся. Там твоё место. > Ну так я себе ряд операций с виртуалками прекрасно оптимизнул. Опять передерг. Никого тут и в мире не интересуют твоё пердольнье с ардуинками, мелкими виртуалочками и прочим компостом. Нужна "плаформа" для возможности быстро решить задачу. Давай наналог PowerCLI для kvm. Тебя больного с баш-портянками в комплекте к сервису нормальным людям не надо. > Более того - я себе _генерацию_ дебутстрапом наваял - с моими кастомизациями. Да понятно что ты с пердуинками там балуешься, но тут ты этим никого не удивишь. >  У вас там уровень сцаного эксплуатанта. Бгыыых. Тебе то виднее у кого что. Гусар-одиночка с пердуинками на шеле пишет письмо сатья-наделле, картина маслом. >  А на этой повар-щели я бы часами долбался с тем же самым, воюя с не теми типами данных мля, и чем там еще. Оно мне надо?! Да все уже поняли что ты головка от патефона. Не пробовал это сделать но мнение имеешь. > А, да, ваш коллега пох (или нах?) таки - вот - плакался что вмварь сожрали. Вас ждут интересные времена! И хорошо что все это - не у меня :) Ты не поверишь. powershell от этого никуда не денется. Как и модули к остальным виртуальным средам. Резюмируя. Ни одного ответа на вопрос ты не дал, только попередергивал. Хвост павлиний распушил. Скажи а вот твоё инфоцыганство здесь помогает тебе дуриков находить?
	Ответить | Правка | Наверх | Cообщить модератору

	685. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 23-Янв-24, 21:48
	> Скопипасть в поискарь и найди что делает 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ообщить модератору

	690. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (690), 24-Янв-24, 06:18
	Резюмируя два. Инфоцыган 294й забыл сам с чего начал(автодополнения нет, коротких команд нет и т.д.). Определенные решения системы становятся плюсами или минусами в зависимости от того по какие системы сравниваются. Лапша шела vs системд конечно в плюс системд. Лапша шела vs пауршел конечно в плюс шела. Алиасы в шеле vs алиасы пауршела конечно в плюс шела. Короткие ничерта не понятные команды в шеле vs длинные опции в системд конечно плюс системд. Короткие ничерта не понятные команды в шеле vs длинные команды по стандартам в пауршел конечно плюс шела. Ну и дальше портянки художественного свиста. В конце не преминул рассказать про свои латентные потребности. Как же 294й да про орган которым думает не расскажет. Инфоцыган, тебе самому позориться не смешно? Ты же не тянешь в дискуссию. На работу тебя подрядить нельзя - это же по комментам видно что ты за работник. Ты так и не рассказываешь. Что у тебя с повреждениями головного мозга была? Чего скрывать то?
	Ответить | Правка | Наверх | Cообщить модератору

	586. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 16-Янв-24, 22:10
	> автодополнение в том уродце не работает по сути никак, А когда пишешь скрипт в любимом редакторе, то  никакого автодополнения для этого чудовища вовсе нет.
	Ответить | Правка | К родителю #382 | Наверх | Cообщить модератору

	322. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 15-Янв-24, 15:23
	Это объясняется тем, что всё это нужно постоянно набирать. Что касательно rust, то сокращения норм, но не норм | и '. Если с ' ещё как-то можно понять зачем пришлось так сделать, то накой хер взяли | понять уже сложно, ровно как и для чего напичкали ЯП вредными элементами функциональщины. В совокупности падает читабельность кода.
	Ответить | Правка | К родителю #258 | Наверх | Cообщить модератору

	439. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от fuggy (ok), 15-Янв-24, 23:35
	То-то наверно лучше в C++ когда звёздочка обозначает сразу 4 разных операции. А без функциональщины, лямбд современный язык уже не язык. В Rust итераторы более читабельные, чем императивная возня с указателями. В C++ между прочем тоже лямбды есть со своим специфическим синтаксисом.
	Ответить | Правка | Наверх | Cообщить модератору

	406. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (-), 15-Янв-24, 20:25
	> First of all, Rust uses a different (often, in my opinion, gratuitously so) syntax Или это значит "мои старческие мозги скатываются в деменцию, новых символов отличных от 'в С/С++' я запомнить не могу; пожалейте старичка"
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	499. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (499), 16-Янв-24, 11:14
	Или это значит, что разработчики Раста не смогли осилить нормальный синтаксис, а сейчас уже поздно.
	Ответить | Правка | Наверх | Cообщить модератору

	574. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (573), 16-Янв-24, 19:03
	Это значит лишь то, что Линус, будучи взрослым человеком, способен определить что является его персональным мнением, а что объективной реальностью, о чём и пишет («in my opinion»). Опеннету бы поучиться у него.
	Ответить | Правка | К родителю #406 | Наверх | Cообщить модератору

	691. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Stellarwind (?), 25-Янв-24, 15:39
	Линуса просто уже ранее настойчиво попросили быть повежливее.. Странно что еще никто не запостил: http://harmful.cat-v.org/software/c++/linus C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C. и про ядро: In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
	Ответить | Правка | Наверх | Cообщить модератору

	692. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от n00by (ok), 25-Янв-24, 17:02
	> Линуса просто уже ранее настойчиво попросили быть повежливее.. > Странно что еще никто не запостил: http://harmful.cat-v.org/software/c++/linus > C++ is a horrible language. It's made more horrible by the fact > that a lot of substandard programmers use it, to the point > where it's much much easier to generate total and utter crap > with it. Quite frankly, even if the choice of C were > to do *nothing* but keep the C++ programmers out, that in > itself would be a huge reason to use C. На это я отвечал в #211 > и про ядро: > In fact, in Linux we did try C++ once already, back in > 1992. > It sucks. Trust me - writing kernel code in C++ is a > BLOODY STUPID IDEA. И на это тоже. Правда, не на цитату Линуса, а на изложенный экспертом похожий смысл. Подсказывать не хочу -- думайте сами над очевидным ляпом, если считает себя знатоком С++.
	Ответить | Правка | Наверх | Cообщить модератору

12. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+7 +/–
Сообщение от Витюшка (?), 14-Янв-24, 21:59
Легендарная битва. Интересно чем закончится. Но сразу и Rust и C++ одновременно - это совсем не good. Эх, жаль некому также топить за Zig (и он недостаточно стабильный для ядра).
Ответить | Правка | Наверх | Cообщить модератору

	15. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Витюшка (?), 14-Янв-24, 22:05
	У C++ сейчас второе, или даже третье дыхание. По моим личным ощущениям. Но за Rust хайп и очень фанатичное комьюнити, которое толкает его куда только можно. Что лучше подходит конкретно для ядра... ОДНОЗНАЧНО zig.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (11), 14-Янв-24, 22:12
	Комьюнити, которое хочет, чтобы кто-то другой на этом языке писал.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
	Сообщение от jjklh (?), 14-Янв-24, 22:28
	По моим, наверное, второе дыхание было с C++0x/C++1y. А вот уже с C++1z/C++2a и дальше язык просто рванул в космос.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	67. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (-), 14-Янв-24, 23:47
	> Что лучше подходит конкретно для ядра... ОДНОЗНАЧНО zig. Как там у него с портабельностью и вообще готовностью к проду? Вот представьте что завтра билдим кернел им для вашего десктопника. Как, прокатит? Без факапищ?
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	101. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Витюшка (?), 15-Янв-24, 01:37
	К сожалению, нет. Я и говорю что некому топить за него. Топить - не только в рассылках писать "а давайте zig", а именно допилить до применения в ядре. Основа там заложена очень крутая.
	Ответить | Правка | Наверх | Cообщить модератору

	385. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 19:03
	> К сожалению, нет. Я и говорю что некому топить за него. > Топить - не только в рассылках писать "а давайте zig", а именно > допилить до применения в ядре. > Основа там заложена очень крутая. Ну, говоря за себя - если у них референсная реализация на LLVM я лучше тогда хруст поизучаю. Когда в gcc нормально запилят, не раньше. Зависеть на 100% от выходок гугли и эпла как-то не хочется. Тем более что эпл уже начал характерную бадягу с особенным, уличным LLVM в Xcode для себя и вторым сортом - для остальных.
	Ответить | Правка | Наверх | Cообщить модератору

	423. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Витюшка (?), 15-Янв-24, 22:01
	В основном языки имеют одну реализацию. С++ в этом плане является прям крайним исключением, просто так сложились обстоятельства. Как и С. Rust никогда не будет допилен в gcc. Я специально смотрел - пилят какие-то энтузиасты, один на магистра в универе учится. Это полуальтруисты. Базовых вещей не умеет. Для ядра это наверное не будет пригодно никогда (в обозримом будущем). Но пропихнуть Rust в kernel это не помешало 😄
	Ответить | Правка | Наверх | Cообщить модератору

	442. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (446), 15-Янв-24, 23:47
	> В основном языки имеют одну реализацию. ...гарантирующую 100% вендорлок, что после си и си++ как бы нефиговый регресс, есчо. > С++ в этом плане является прям крайним исключением, просто так сложились обстоятельства. Да, нашлись те кого вендорлоки заколебали. И я вовсе не для того пришел в опенсорс чтобы наслаждаться вендорлоками. Сюрприз! Never again! Так что у меня будет или так - или я поюзаю си и си++, мне хватит. > Как и С. Rust никогда не будет допилен в gcc. Я специально смотрел - пилят > какие-то энтузиасты, один на магистра в универе учится. Это полуальтруисты. Однако вон там уже и borrow checker прорезается. Во всяком случае я вижу какие-то коммиты связанной инфраструктуры. А так Столлман написал первую версию gcc, Торвальдс накатал в 1 лицо Linux, упрямец Кент cow файлуху своротил. Большие вещи начинаются с малого. > Базовых вещей не умеет. Для ядра это наверное не будет пригодно никогда > (в обозримом будущем). Но пропихнуть Rust в kernel это не помешало 😄 Ну он так пропихан что пока на него ничего реально не завязано. И кмк решение будет ли на него что-то завязано более плотно - ощутимо зависит от того будет ли gccrs юзабельным или нет. Майнтайнеры линуха тертые калачи и влопаться в вендорлок? Ну, эт, Торвальда уже пробовали так лохануть в Bitbaker. И где этот их bitbaker теперь?...
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 03:05
	> У C++ сейчас второе, или даже третье дыхание. По моим личным ощущениям. Почему? Они насмотрелись на rust и другие языки и начали стандартизовывать нужные всем вещи?
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	175. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (175), 15-Янв-24, 07:45
	Скорее они насмотрелись на D, а хайп вокруг безопасности заставил оторвать кое-что от стула.
	Ответить | Правка | Наверх | Cообщить модератору

	317. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+4 +/–
	Сообщение от Аноним (313), 15-Янв-24, 15:07
	> заставил оторвать кое-что от стула Пару ножек?
	Ответить | Правка | Наверх | Cообщить модератору

	387. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
	Сообщение от Аноним (-), 15-Янв-24, 19:06
	>> У C++ сейчас второе, или даже третье дыхание. По моим личным ощущениям. > Почему? Они насмотрелись на rust и другие языки и начали стандартизовывать нужные > всем вещи? А в rust что-то вообще СТАНДАРТИЗОВАНО?! У него ж ни единой версии стандарта нет. По крайней мере от нормальных standard body. Не, куча хипстеров хаотично корежащих синтаксис под заскоки левой своей пятки и приказ своего корпо-хозяина - это не оно. Вообще совсем. И вот как-то так получается что у хруста нет вообще ни 1 стандарта. В отличие от C++.
	Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

	395. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Советский инженер (ok), 15-Янв-24, 19:35
	типа на стандартном С можно ядро написать!? вот умора, язык разработан для написания ядер и прочей системщины более 50 лет назад. имеет нескольео стандартов ,но без гну/ms костылей ядра ОС так и не собираются. и эти же "стандартизаторы" вещают про стандарты.
	Ответить | Правка | Наверх | Cообщить модератору

	445. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (446), 15-Янв-24, 23:50
	> типа на стандартном С можно ядро написать!? Ну, почти. Режим freestanding официально специфицирован с C99 аж. Там правда пары вещей не хватает, это таки вот именно гнутые экстеншны. > вот умора, язык разработан для написания ядер и прочей системщины более 50 > лет назад. имеет нескольео стандартов ,но без гну/ms костылей ядра ОС так и не > собираются. и эти же "стандартизаторы" вещают про стандарты. Потому что в целом код conformant, плюс-минус очень небольшое число мест. А хруст вообще хаотичная помойка, развиваемая абы как. Захотели и перефигачили синтаксис. Наверное так и надо...
	Ответить | Правка | Наверх | Cообщить модератору

	500. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Советский инженер (ok), 16-Янв-24, 11:20
	> Там правда пары вещей не хватает ... дооо, язык создавался для симстемщины и ядер ОС, но стандартизировать решили что-то другое. Отличные стандарты! 🤣 >А хруст вообще хаотичная помойка, развиваемая абы как. Захотели и перефигачили синтаксис. Именно поэтому компиляция ядра клангом периодически отваливается? ведь так? Это не потому что гнугники что-то постоянно подпиливают в своих нестандартных экстеншонах? СТАНДАРТ !!! о таком только мечтать!
	Ответить | Правка | Наверх | Cообщить модератору

	650. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 19-Янв-24, 19:17
	> дооо, язык создавался для симстемщины и ядер ОС, но стандартизировать решили что-то > другое. Отличные стандарты! 🤣 Хрустики даже и так не смогли. Все познается в сравнении... которое они и не выдерживают пока, демонстрируя шоу "хаотичная помойка имени питоняш". >>А хруст вообще хаотичная помойка, развиваемая абы как. Захотели и перефигачили синтаксис. > Именно поэтому компиляция ядра клангом периодически отваливается? ведь так? В хрусте системщина вообще в зачаточном состоянии и там вообще не привалилось еще толком - чтобы вообще начать отваливаться. Иногда удается что-то на проволоку и изоленту примотать, чуть ли не с gcc'шным, мля, линкером на страпоне, ибо свой - УГ. Но это видимо не пахнет. Но конечно вы можете скачать ночнушку, высокобезопастным инновационным curl | sh. Там может быть если повезет, уже почти, вот вот, ых, ых, ых... как как грите, фукмсию решили отменить когда как раз почти треть переписали? Ну, во, все правильно сделали. Сразу видно wannabe-успешный проект. Успешно присоединится к Wave, Plus, Picasa и кому там еще в Валхалле. > Это не потому что гнугники что-то постоянно подпиливают в своих нестандартных экстеншонах? > СТАНДАРТ !!! о таком только мечтать! "Но тут снизу постучали" - это были хрустики.
	Ответить | Правка | Наверх | Cообщить модератору

	660. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Советский инженер (ok), 20-Янв-24, 11:13
	>Хрустики даже и так не смогли. Хрустики смогли пробиться в ядро, а С++ со всеми своими стандартами не смог. Очередной пример, указывающий что стандарты это что-то бесполезное на практике. >чуть ли не с gcc'шным, мля, линкером на страпоне, нет никакого gcс'шного, мля, линкера. есть GNU Binutils. и тут хрустики тоже поступили практично, как и gcc'шники.
	Ответить | Правка | Наверх | Cообщить модератору

	662. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 20-Янв-24, 12:17
	> Хрустики смогли пробиться в ядро, а С++ со всеми своими стандартами не смог. Они пока так пробились что постоянно переделывают свое месиво, постоянно надо самую-самую ночнушку, иначе нихрена не получится, в общем, самый прод. Я допускаю что из этого постепенно может и получится что-то дельное. Но пока это выглядит весьма хаотично, а нужда постоянно тягать начнушки яп намекает на д@рьмовый дизайн где многое не предусмотрели. > Очередной пример, указывающий что стандарты это что-то бесполезное на практике. Ну да, намного лучше, когда кучка хайпующей хипстоты вываливает в синтакс какое-то уг для ублажения сиюминутных хотелок своего вендора. А в результате синтаксис корежат хуже чем у питона, без скачки ночнушки нихрена не работает, и полезные продукты на этом уже прямо захватили мир. Куда там плюсерам до этого, действительно. >>чуть ли не с gcc'шным, мля, линкером на страпоне, > нет никакого gcс'шного, мля, линкера. есть GNU Binutils. Как минимум это все - вообще не заслуга хрустиков. > и тут хрустики тоже поступили практично, как и gcc'шники. Ну вот я подожду gccrs и там подумаю - надо оно мне или нет. LLVMный змейгорыныч мне не приболел, я не фанат ни гугли ни эппла, это те еще кидалы.
	Ответить | Правка | Наверх | Cообщить модератору

	679. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Советский инженер (ok), 21-Янв-24, 21:44
	> Они пока так пробились что постоянно переделывают свое месиво ... ты как ни плюйся желчью, а факт есть факт. раст в ядре. а плюсы нет. >Куда там плюсерам до этого, действительно. точно не в ядро. >> нет никакого gcс'шного, мля, линкера. есть GNU Binutils. >Как минимум это все - вообще не заслуга хрустиков. это как раз показывает что хрустики практичные. и да, это так же не заслуга приплюснутых. >Ну вот я подожду gccrs и там подумаю ага, держи нас в курсе. всем очень интересно (нет).
	Ответить | Правка | Наверх | Cообщить модератору

	686. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 23-Янв-24, 21:54
	> ты как ни плюйся желчью, а факт есть факт. раст в ядре. а плюсы нет. В ядре много чего было. И не все из этого с нами сейчас. Так что это само по себе еще ничего не означает. С другой стороны - может из этого и выйдет что-то дельное постепенно. Но пардон, качать ночнушки компилера - не стандарт а хипста-треш. >>Куда там плюсерам до этого, действительно. > точно не в ядро. Они чем-то принципиально хуже хрустиков? > это как раз показывает что хрустики практичные. Если бы они были бы практиными, потратили бы немного больше времени на архитектуру и изучение чужих фэйлов, тогда не приходилось бы перекачивать постоянно компилер и корежить синтаксис. Но с этим кажется облом вышел. > и да, это так же не заслуга приплюснутых. А бинутилсам плюсы юзать не разрешили случайно? В гцц - точно можно. >>Ну вот я подожду gccrs и там подумаю > ага, держи нас в курсе. всем очень интересно (нет). Да вы и кернел линуха врядли трогаете даже трехметровой палкой, так что...
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (6), 14-Янв-24, 22:06
	>Эх, жаль некому также топить за Zig (и он недостаточно стабильный для ядра). Возможно потому что его компилятор работает только на последних версиях систем?
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	23. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Витюшка (?), 14-Янв-24, 22:15
	Там llvm. Всё что поддерживает llvm в целом должен или может поддерживать Zig. https://docs.kernel.org/kbuild/llvm.html Да и ядро и так компилится с помощью llvm.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (41), 14-Янв-24, 22:50
	Вот только для ядра будет требование сборки с использованием gcc. Для раста из-за этого начали делать gccrs, было утверждено добавление GCC 13 (https://www.opennet.me/opennews/art.shtml?num=57491) в виде беты и так далее. А что у Зига? Разве есть хоть какие-то подвижки?
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Витюшка (?), 14-Янв-24, 23:26
	Ну, вот и нужны кто будет двигать Zig и возьмётся за добавление к gcc. Это должны быть компании, но таких пока нет.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 14-Янв-24, 23:48
	> Там llvm. Всё что поддерживает llvm в целом должен или может поддерживать Zig. Тогда EPIC FAIL - он получает тот же отлуп что и хруст в сравнимой дискуссии в git, ибо LLVM не особо то кроссплатформенная штука и далеко не все архитектуры поддерживает. Здорово сливая GCC по поддержке железа.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	76. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–5 +/–
	Сообщение от Аноним (-), 15-Янв-24, 00:03
	У LLVM все прекрасно с поддержкой платформ. Это GCC поддерживает всяких хлам и некроплатформы
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от jjklh (?), 15-Янв-24, 03:38
	> У LLVM все прекрасно с поддержкой платформ. > Это GCC поддерживает всяких хлам и некроплатформы ну, ладно выкинут поддержку неподдерживаемых платформ из ядра, потому что, допустим, ядро пишут для llvm, а не наоборот. Но с этим https://clangbuiltlinux.github.io/ что делать? Оно ж тупо не собирает ядро трехлетней давности, Карл!!!
	Ответить | Правка | Наверх | Cообщить модератору

	226. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–2 +/–
	Сообщение от Аноним (41), 15-Янв-24, 10:53
	> ну, ладно выкинут поддержку неподдерживаемых платформ из ядра При чем тут все платформы? Зачем тебе новейший драйвер напр. сетевухи на 100Гб на PDP-11 или System/370? Сильно убудет если он не будет там поддерживаться, если он не компилится из-за шланга? Шланг даже m68k тяшет. Приведи пожалуйста пример, отсутствие какой архитектуры - блокер. > Оно ж тупо не собирает ядро трехлетней давности А ты обратил внимание, что андроиды собираются все, кроме android15‑6.6 старыми шлангами? Не задумался почему так? Может просто гугл следит за этим и исправляет в ядре/шланге что нужно? Вот если и в ядре будут следить, то компилится будет. Или ты думаешь что gcc просто самом собой начинает поддерживать все без проблем?
	Ответить | Правка | Наверх | Cообщить модератору

	390. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 19:12
	> У LLVM все прекрасно с поддержкой платформ. > Это GCC поддерживает всяких хлам и некроплатформы BSDшники уже пробовали рассказывать сказку про (не)нужные всем фичи. И где они теперь? Вот и вы туда же с этим всем отправитесь. По тем же причинам. Мне вот например не нужны тулчейны где так внаглую лечат что мне (не)нужно. Я и не буду такими тулчейнами пользоваться.
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	602. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (20), 17-Янв-24, 04:29
	Да нет там никакой битвы, тем более легендарной. Очень вялая дискуссия где одни челы говорят, что Раст всё равно лучше, а другие челы обсуждают все причины, по которым С++ впилить в кернел не получится, во всяком случае что бы с++ при этом оставался полезным.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

13. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+6 +/–
Сообщение от Аноним (13), 14-Янв-24, 22:04
Линус сам прекрасно осознаёт, что из-за своего ЧСВ и ощущения хозяйскости наговорил глупостей. Но из-за такого китайского концепта как "потеря лица" он не может признать, что говорил глупости. Разумеется, ядро давно необходимо перевести на C++ хотя-бы из-за его AST-безопасных inline-функций, улучшенной проверки типов в вызовах функций и compile-time вычислений (да, я знаю, они тяжёлые. Но в C++ есть модули, в них такие вычисления закешируются). Но необходимо ввести жёсткую конвенцию по написанию кода о том, что должно линковаться на уровне хэдеров, что - статически, а что - динамически, и разработать линтер. Без линтера тут никуда. За header-only нужно сразу от разработки отлучать с волчьим билетом.
Ответить | Правка | Наверх | Cообщить модератору

	79. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (115), 15-Янв-24, 00:09
	Линус может сказать, что уже прошло много времени и язык существенно изменился в лучшую сторону, и всё. Ты как тогда не хотел понимать какие претензии были к с++, так сейчас не будешь разбираться что же изменилось в лучшую сторону. > Разумеется, ядро давно необходимо перевести на C++ хотя-бы из-за... Кроме из-за ещё есть и аргументы против. Твоё выдёгивание только из-за' ничего не стоит
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–2 +/–
	Сообщение от Аноним (94), 15-Янв-24, 00:53
	>Линус может сказать, что уже прошло много времени и язык существенно изменился в лучшую сторону, и всё. Он высказался не о языке. Он не подумав (зачем ему думать, он же диктатор-хозяин-барин и ядро - его собственность! правда потом спонсоры ему пояснили, who is who.) ляпнул, что недопуск C++ в ядро - это мера по недопуску в ядро программистов N-го сорта - программистов на C++. Если теперь он допустит в ядро программистов на C++, то ему придётся признавать 3 вещи: 1. что программисты на C++ - это не программисты N-го сорта 2. что Линус необоснованно из личной гордыни задел достоинство программистов на C++ 3. что оттолкнув по мотивам личной гордыни и неприязни определённую группу программистов Линус проявил непрофессионализм и замедлил развитие проекта
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 15-Янв-24, 02:14
	Не знаю о каком именно высказывании говоришь, я видел только где в основном обсуждался ЯП
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от 11 (?), 15-Янв-24, 09:18
	«C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.» Linus Torvalds
	Ответить | Правка | Наверх | Cообщить модератору

	211. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от n00by (ok), 15-Янв-24, 10:23
	> a lot of substandard programmers use it Линус знатно потроллил. Никто ведь не заставлял принимать "a lot" на свой счёт.
	Ответить | Правка | Наверх | Cообщить модератору

	318. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (313), 15-Янв-24, 15:11
	> то ему придётся признавать 3 вещи: - что теперь программисты N-го сорта допущены в ядро.
	Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

	368. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (368), 15-Янв-24, 18:33
	Тут у Линуса осталось 3 варианта действий: 1. покаяться за вред, нанесённый проекту, и извиниться перед крестовиками. Будет больно и неприятно, но возможно тогда его оставят. Возможно... Не значит, что гарантированно. Тут главное - грамотно обосновать, почему смена руководства нанесёт проекту больше вреда, чем пользы. Если обоснует - то останется. Но лицо потеряет. 2. играть в несознанку и дожидаться, пока всех доставшего эгоиста прирудительно не снимут. 3. одобрить включение C++ в проект и попытаться замять историю с балабольством. Не выйдет - история широко известная, тут же найдутся те, кто включит аргумент "раз программисты на C++ плохие, то зачем ты их в ядро допустил, лидер ты наш Акелла? если они вдруг стали хорошими, хотя мы все знаем, что с обыдлением всё становится хуже, то как же так получилось, что твои слова противоречат реальности, может ты просто не хочешь признавать свою ответствееность за свой базар и свои действия? Зачем нам такой лидер?" Линус загнал себя в цугцванг сам своим безответственным поведением. На мой взгляд ему наиболее выгодно идти по пути 1. Но это сторонний взгляд, что в башке у Линуса - никто не знает.
	Ответить | Правка | Наверх | Cообщить модератору

	410. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 20:38
	Лол, а почему он не может сказать "раст уже в ядро добавили, зачем там третий язык?" Более того, а за что каяться? От добавления С++ ядро лучше бы не стало, по аналогии с Сишкой С89 сидели бы на С++98 до 2022 года( Так что никаких смартпойнтеров и прочих даров цивилизации. Более того подозревая, что дудуки пилящие ядро начали бы писать в стиле "как умеют". ИМХО тогда стало бы еще хуже.
	Ответить | Правка | Наверх | Cообщить модератору

	460. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (460), 16-Янв-24, 01:14
	>Лол, а почему он не может сказать "раст уже в ядро добавили, зачем там третий язык?" Какой третий? Весь сишный код фиксится до совместимости с clang++  и объявляется плюсовым.
	Ответить | Правка | Наверх | Cообщить модератору

	587. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 16-Янв-24, 22:32
	>>Линус может сказать, что уже прошло много времени и язык существенно изменился > Он высказался не о языке. Речь о c++ образца 2007г или ранних. Вы сами то хотите на них писать? Ладно, это мелочь.   А по существу. Тогда был подъем моды на объектное программированиее, причем где надо и ненадо, и даже там где это вредно.   И фраза про С++ "намного легче генерировать полную чушь" была не безосновательна. Дай дураку инструмет, на котором он легко сделает говнокод, и он именно его и напишет.   Аналогична ситуация с количеством говнокода на Делфи и Питоне, и совсем не потому что языки плохи, а потому что позволяют навалить кучу по быстрому.
	Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

	86. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Синий попугай (ok), 15-Янв-24, 00:18
	Разрешите поинтересоваться? Что именно подразумевает header only и почему это настолько плохо?
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	97. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (97), 15-Янв-24, 01:21
	>Что именно подразумевает 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ообщить модератору

	164. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 15-Янв-24, 06:45
	> и в каждый бинарь включена своя копия реализации. Подтверждением в виде дизассемблерного листинга не порадуете?
	Ответить | Правка | Наверх | Cообщить модератору

	267. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 12:56
	>> и в каждый бинарь включена своя копия реализации. > Подтверждением в виде дизассемблерного листинга не порадуете? Не тормози, сникерсни! Если либа в .c/.cpp и ее отдельным .so сделали - все три проги поюзают один shared lib, если либу так собрать. Будет реюз кода либы. А если это все было в header-only - опа, хидер .so не сделаешь! И все три получат свои приватные реализации фич которые они оттуда использовали и реюз кода не состоится. Это и есть обратная сторона header only. И интересно, чем тут дизассемблер поможет? Бывают конечно еще псевдолибы где кроме препроцессора и определений нихрена нет, но он видимо про полновесные хидеры с кодом.
	Ответить | Правка | Наверх | Cообщить модератору

	360. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 18:12
	А если у вас библиотека шаблонов, то методы с шаблонными параметрами тоже приходется в заголовочниках.
	Ответить | Правка | Наверх | Cообщить модератору

	461. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (460), 16-Янв-24, 01:18
	Шалонная часть STL - это тривиальные вещи, компилируемые в несколько процессорных инструкций. Нетривиальные находятся в libstdc++.so.
	Ответить | Правка | Наверх | Cообщить модератору

	522. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 16-Янв-24, 14:18
	Большинство основных STL частей чисто шаблонные. Например, тот же std::map генерирует разный код для всех используемых комбинаций типов. В so-ке только темплейтнонезаисимые части и некоторые заранее сгенерированные шаблоны для типичных типов. Во время компиляции весь это код всё равно генерируется для каждого c++ исходника и дубликаты выкидываются только на стадии линковки
	Ответить | Правка | Наверх | Cообщить модератору

	524. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 16-Янв-24, 14:26
	STL - это алгоритмы, итераторы и контейнеры, созданные Степановым и Ли. Для стандартной библиотеки лишь RTTI затруднительно реализовать как header-only, но оно и не надо в ядре. Все эти сказки про .so оставьте идеологам GPL, в ядро код и без них принимается только под этой лицензией.
	Ответить | Правка | К родителю #461 | Наверх | Cообщить модератору

	523. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 16-Янв-24, 14:22
	>>> и в каждый бинарь включена своя копия реализации. >> Подтверждением в виде дизассемблерного листинга не порадуете? > Не тормози, сникерсни! Если либа в .c/.cpp и ее отдельным .so сделали > - все три проги поюзают один shared lib, если либу так > собрать. Будет реюз кода либы. Тормозят пока что эксперты и внедрители Си++ в Linux. У меня стандартная библиотека для ядра header-only была 15 лет назад.
	Ответить | Правка | К родителю #267 | Наверх | Cообщить модератору

	663. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 20-Янв-24, 12:25
	> Тормозят пока что эксперты и внедрители Си++ в Linux. У меня стандартная > библиотека для ядра header-only была 15 лет назад. И это все круто и офигенно - потому что что? С чисто практической точки зрения, если вы завтра перестанете существовать, вместе со своей либой - для меня изменится ну вот например что? Ах, ничего? Тогда и смысла передо мной рисоваться со всем этим - примерно ноль. Набивайте себе цену перед теми кому ваши поделия полезны, имхо. Это не я.
	Ответить | Правка | Наверх | Cообщить модератору

	668. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 20-Янв-24, 15:28
	>> Тормозят пока что эксперты и внедрители Си++ в Linux. У меня стандартная >> библиотека для ядра header-only была 15 лет назад. > И это все круто и офигенно - потому что что? Потому что ты придумал тезис "круто и офигенно", что бы приписать его мне. В надежде на что? > С чисто > практической точки зрения, если вы завтра перестанете существовать, вместе со своей > либой - для меня изменится ну вот например что? Ах, ничего? > Тогда и смысла передо мной рисоваться со всем этим - примерно > ноль. Набивайте себе цену перед теми кому ваши поделия полезны, имхо. > Это не я. "Я три дня гналась за вами, чтобы сказать, как вы мне безразличны!" (ц)
	Ответить | Правка | Наверх | Cообщить модератору

	486. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (486), 16-Янв-24, 07:32
	>Если всё линкуется в один бинарник, то вообще может быть ошибка линковки чудик не знал про #pragma once, но уже требует кого-то там вон из профессии :)
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	589. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (589), 16-Янв-24, 23:13
	Э... Очевидно имелось ввиду именно линковка. Один файл компилируется в объектник с включенным заголовочником. Другой файл генерируется объектник с включенным  заголовочником. Оба содержат одинаковые сгенерированные функции. Теперь линкуем это в один бинарь и получаем ожидаемый нежданчик.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+4 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 03:03
	> За header-only нужно сразу от разработки отлучать с волчьим билетом. Взял и boost опозорил.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	151. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (115), 15-Янв-24, 04:57
	STL же, boost сама по себе помойка
	Ответить | Правка | Наверх | Cообщить модератору

	213. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 15-Янв-24, 10:26
	> STL же Любопытно, сколько из присутствующих видели библиотеку Степанова и Ли.
	Ответить | Правка | Наверх | Cообщить модератору

	275. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 13:21
	Покажи, посмотрим.
	Ответить | Правка | Наверх | Cообщить модератору

	421. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (421), 15-Янв-24, 21:52
	Если долго вглядываться в бездну, бездна начнет вглядываться в тебя. А вообще, всё зависит от прямоты рук. # Непустых строк: $  grep -c \. /usr/include/c++/*/vector /usr/include/c++/13.2.1/vector:131  # GCC /usr/include/c++/v1/vector:3045  # LLVM # Включений: $  grep -c \#include /usr/include/c++/*/vector /usr/include/c++/13.2.1/vector:10  # GCC /usr/include/c++/v1/vector:50  # LLVM
	Ответить | Правка | Наверх | Cообщить модератору

	422. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (421), 15-Янв-24, 21:55
	$ pacman -Qo /usr/include/c++/*/ /usr/include/c++/13.2.1/ is owned by gcc 13.2.1-3 /usr/include/c++/v1/ is owned by libc++ 16.0.6-1 /usr/include/c++/v1/ is owned by libc++abi 16.0.6-1
	Ответить | Правка | Наверх | Cообщить модератору

	526. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 16-Янв-24, 14:34
	Это не то.
	Ответить | Правка | К родителю #421 | Наверх | Cообщить модератору

	133. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 03:04
	> Разумеется, ядро давно необходимо перевести на C++ хотя-бы из-за его AST-безопасных inline-функций, улучшенной проверки типов в вызовах функций и compile-time вычислений Почему бы это просто в C не добавить?
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	194. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (194), 15-Янв-24, 09:44
	Давно есть. Человек просто поумничать хотел
	Ответить | Правка | Наверх | Cообщить модератору

	361. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 18:14
	Шаблонов нет, а compile-time вычисления есть?
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (238), 15-Янв-24, 11:20
	C с этими добавлениями называется C++ :).
	Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

	298. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 15-Янв-24, 14:16
	Похожими вопросами многие задавались ещё лет 15 назад, однако время прошло и Си как был бревном, так им и остался.  С другой стороны, плюсы постепенно движутся куда нужно, но медленно. Скорее уж в плюсах появится ABI, чем в Си занесут новые фичи
	Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

	150. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от fuggy (ok), 15-Янв-24, 04:44
	Зачем переписывать на C++ чтобы потом пришлось переписывать на Rust умалчивается.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	155. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (115), 15-Янв-24, 05:13
	На rust переписывать не придётся. Его засунули в ядро чтобы шумные детишки наигрались молча с какой и потом остали от ядра сами
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (173), 15-Янв-24, 07:41
	Тоже так считаю.
	Ответить | Правка | Наверх | Cообщить модератору

	253. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (253), 15-Янв-24, 12:38
	Раст - навсегда в ядре. Учитывая, сколько уве в сетевых подсистемах ведра на сишке, раст безалтернативен. А вот всякие алгоритмы сморт пойнтерс в плюсах далеко не каждый будет подключать, ибо плюсы и так громоздкие.
	Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

	302. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (115), 15-Янв-24, 14:28
	Ничего нигде не бывает навсегда, ты сам тут не навсегда. Как засунули, так и уберут. Тем более если говорить о языке в ядре, на котором пока что ничего важного нет кроме hello world. И если оно уже на Си и хорошо работает, значит вполне себе альтернативы есть - тот же Си. Учись рассуждать у мастера логики. >  А вот всякие алгоритмы сморт пойнтерс в плюсах далеко не каждый будет подключать, ибо плюсы и так громоздкие. Несёшь какую-то чушь, но можно поговорить об интеграции. Как уже заметили в обсуждении, c++ проще интегрируется в существующий код - точнее, интегируется, а rust - нет. У rust в лучшем случае какое-то время будет ниша штучных драйверов. Если рядом с rust появятся плюсы, то большинство разработчиков просто пойдёт по пути наименьшего сопротивления и выберет c++. А объяснить зачем нужно менять правильно приготовленные плюсы на rust уже намного сложнее.
	Ответить | Правка | Наверх | Cообщить модератору

	310. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (253), 15-Янв-24, 14:51
	Дело в том, что решают корпорации, они пишут ядро за свои деньги, и они выбрали раст. Платиновым спонсорам нужен раст, а плюсы им не нужны. Вот так вот...
	Ответить | Правка | Наверх | Cообщить модератору

	323. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 15-Янв-24, 15:28
	Когда какой-нибудь Google начнёт массово релизить либы и продукты на rust вместо С++ и Go, тогда можно будет считать что  выбрали. Пока что это местячковые потуги, как и со всеми остальными модными технологиями. И опять таки, ничего не бывает навсегда, особенно у корпораций: у них бабла много и не жалко выкинуть игрушку на помойку в любой момент
	Ответить | Правка | Наверх | Cообщить модератору

	362. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (293), 15-Янв-24, 18:18
	>Учитывая, сколько уве в сетевых подсистемах ведра на сишке, раст безалтернативен. А сколько на сегодня Раста в сетевой подсистеме ядра? Помоему, пока что хрен целых, хрен десятых.
	Ответить | Правка | К родителю #253 | Наверх | Cообщить модератору

	351. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (341), 15-Янв-24, 17:20
	Помимо политики была ещё одна причина - исключения в C++, хотя Линус тогда* не говорил, почему нельзя использовать плюсы без них. * https://lore.kernel.org/lkml/Pine.LNX.4.58.0401192241080.231.../
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	530. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 16-Янв-24, 14:54
	Линус и не развернул тему "fundamentally broken". В ядре NT возможно использовать исключения на IRQL PASSIVE_LEVEL, если очень захочется разрешить политикой проекта.
	Ответить | Правка | Наверх | Cообщить модератору

19. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
Сообщение от Аноним (19), 14-Янв-24, 22:11
>В качестве минимальной упоминается использование спецификации C++14 Не, нужно сразу 26 в редакции clangа на сегодняшний день брать. Потому что без ranges делать compile-time вычисления невесело. Хоть в шланге и нет ещё полноценных ranges, уже то что есть - очень полезно и убирает кучу того, что либо вручную приходилось держать в актуальном состоянии или скриптом генерировать (напр. индекс максимального элемента массива из фиксированных compile-time значений). magic_enum вообще офигенно полезная либа. Она хоть и header-only, но она не приводит к оверхеду на каждый включённый экземпляр, как если бы nlohmann json включили в один модуль, а потом во второй, и всё header-only. Другая офигенна полезная либа - это ctre.
Ответить | Правка | Наверх | Cообщить модератору

	195. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (194), 15-Янв-24, 09:49
	вот честно... чем пользоваться этой синтаксической ахинеей проще написать в 5 строк скрипт на том же питоне для предвычислений
	Ответить | Правка | Наверх | Cообщить модератору

	279. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (279), 15-Янв-24, 13:25
	И огрести на ровном месте проблем, в частности тащить 2 реализации одного и того же на разных языках и гемороиться с интеграцией питоньего скрипта в систему сборки, чтобы каждый раз не пересобирало? Не, спасибо, я лучше ranges поюзаю.
	Ответить | Правка | Наверх | Cообщить модератору

	309. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 15-Янв-24, 14:47
	> И огрести на ровном месте проблем, в частности тащить 2 реализации одного > и того же на разных языках и гемороиться с интеграцией питоньего > скрипта в систему сборки, чтобы каждый раз не пересобирало? Не, спасибо, > я лучше ranges поюзаю. А потом через полгода выйдет новый пихон - и вообще сборочница сломается. Питонженетормозит и у него отличная совместимость между версиями. Вам что, впадлу чтоли код подправить? Да, блин, знаете, когда начинает сыпаться с 9000 разных сторон - таки, впадлу!
	Ответить | Правка | Наверх | Cообщить модератору

	357. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 15-Янв-24, 17:58
	В пакетах всё ещё можно поставить второй питон. Так что да, ничего не сломается. Конечно, для задач выше он не нужен, а именно - любая кодогенерация зло.
	Ответить | Правка | Наверх | Cообщить модератору

	394. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 19:27
	> В пакетах всё ещё можно поставить второй питон. Это в каких бы таких пакетах? Поддержку питона2 вынесли сами питоняши еще сколько там назад. Линуксные дистры и вынесли его - они быть святее папы римского не собираются, майнтайня софт за питоняш. > Так что да, ничего не сломается. Конечно, для задач выше он не нужен, а именно > - любая кодогенерация зло. Оно и видно что там не сломается. В дебиане 12 было аж 3000 чтоли багов на эту тему. Всего-то, блин. Они и задропали половину софта к хренам, им что, больше всех надо?!
	Ответить | Правка | Наверх | Cообщить модератору

	424. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (421), 15-Янв-24, 22:04
	Итерация свойственна человеку, кодогенерация божественна.
	Ответить | Правка | К родителю #357 | Наверх | Cообщить модератору

	289. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 13:45
	Засуньте ваш Шланг в... Ядрописатели требуют обязательность сборки GCC.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	371. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (371), 15-Янв-24, 18:39
	Шланг отстаёт от gcc по фичам языка, но опережает по строгости, статическому анализу, удобству использования и скорости результирующего кода. Тех же концептов до сих пор нет, и это создаёт проблемы для кода, который написан под gcc. Если шлангоспецифичные расширения не юзать - то gcc соберёт то, что собирается шлангом. Поэтому ориентироваться надо именно на собираемость шлангом.
	Ответить | Правка | Наверх | Cообщить модератору

	383. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (293), 15-Янв-24, 19:01
	Если разработчики ядра захотят обязательно эти концепты, то разработчики GCC пойдут навстречу. Почему нет?
	Ответить | Правка | Наверх | Cообщить модератору

	467. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (460), 16-Янв-24, 02:10
	в шланге нет концептов, в gcc они есть. Если задействовать код на концептах - то шлангом собираться не будет. А собирать лучше шлангом.
	Ответить | Правка | Наверх | Cообщить модератору

	590. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (589), 16-Янв-24, 23:16
	С чего вдруг лучше то?
	Ответить | Правка | Наверх | Cообщить модератору

	636. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (636), 18-Янв-24, 23:59
	См. рис. 1.
	Ответить | Правка | Наверх | Cообщить модератору

22. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+9 +/–
Сообщение от Placeholder (ok), 14-Янв-24, 22:14
Как раз схожесть синтаксиса это скорее надостаток, потому что внешнее соходство вообще не означает что под капотом будет схожее поведение. Этакие "ложные друзья переводчика".
Ответить | Правка | Наверх | Cообщить модератору

	26. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (173), 14-Янв-24, 22:25
	Так и си этого не гарантирует как и большинство высокоуровневых языков с >1 компиляторов.
	Ответить | Правка | Наверх | Cообщить модератору

	216. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от n00by (ok), 15-Янв-24, 10:31
	Это гарантируют стандарты и Си, и Си++, а вот смешивание языков может привести к проблемам. Например, наверняка потребуют запретить перегрузку, что бы не вызвать у некоторых культурный шок.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Bottle (?), 14-Янв-24, 22:28
	Главные различия, которые следует запомнить: В стандарте C++ нет Value Length Array (хотя GCC, Clang поддерживают их), приведение типов немного иное, ABI отлично.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	31. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (31), 14-Янв-24, 22:34
	В ядре тоже нету VLA. В стандаре C99 было, но потом, поняв ошибку, сделали это в следующем стандарте  опциональным.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (58), 14-Янв-24, 23:38
	А в чём проблема VLA? Лучше с alloca и указателями для того же самого геморроиться и статическому анализатору палки в колёса ставить?
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 14-Янв-24, 23:54
	> А в чём проблема VLA? Лучше с alloca и указателями для того же самого > геморроиться и статическому анализатору палки в колёса ставить? В том что... 1) Никогда не знаешь когда этот код навернется. 2) Способов узнать навернется ли он - нет. 3) В стандартах "C" нет слова "стэк" от слова вообще. 4) Поэтому вы в душе не и...те сколько его доступно и плохо ли arr[n] или прокатит. А теперь представьте что у вас по рандому будет грохаться ЯДРО по причине "переполнение стека". Как вам такая перспектива? Этот аспект конечно существует всегда но с именно VLA он вылезает наиболее зло и часто. Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000. При том вы даже узнать не можете ок ли такой n или нет. В отличие от мануальной аллокации где хотя-бы зввернут. А тут - сразу SIGSEGV какой бу, или что там. Круто, да?!
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (99), 15-Янв-24, 01:30
	От переполнения стэка ни один код не защищён. И ни один код не защищён от исчерпания памяти. > Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000. При таком n, даже если всё в куче будет, на большинстве компов грохнется. И всё тут. И там и там надо ограничивать разрешённые значения N.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (115), 15-Янв-24, 02:08
	Всего лишь 100Мб, не грохнется. Тем более запрос через аллокатор никогда не приведёт к сваливаю
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (126), 15-Янв-24, 02:51
	Тьфу, действительно мегабайт, перепутал с гигами. >Тем более запрос через аллокатор никогда не приведёт к сваливаю С выделением на стеке тоже можно проверять, не случится ли переполнения. Но built-inа для этого в компиляторах нет.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 15-Янв-24, 02:56
	Но почему-то проверок места на стеке нигде нет
	Ответить | Правка | Наверх | Cообщить модератору

	297. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 14:10
	> Всего лишь 100Мб, не грохнется. 1) Ну попробуй так на AtMega какой-нибудь :). Правда, грохаться этот убогий не умеет чисто технически, ибо хардварных exceptions у авр нет как класса - но каким-нибудь интересным глюком в корчах в его фирмваре наверное воздастся. 2) Даже если это ОС - а ты уверен что сто мегов в вот именно стеке процесса таки дадут? > Тем более запрос через аллокатор никогда не приведёт к сваливаю Это не обязан быть запрос через аллокатор... одна из причин по которым операции на стеке быстрее операций в heap. Фича стека в том что он аллоцируется и деаллоцируется автоматически, чаще всего с нехилым подпором железом. Антифича состоит в том что вы не можете узнать прокатило это или нет иначе как fault handler'ом "все пропало шеф!" в тыкву (или жесткими глюками если оно так не умело).
	Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

	326. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (115), 15-Янв-24, 15:34
	Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти? Речь про кучу, если вдруг проблемы с чтением > Фича стека в том что он аллоцируется и деаллоцируется автоматически, чаще всего с нехилым подпором железом. Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны железа самая топорная
	Ответить | Правка | Наверх | Cообщить модератору

	405. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 20:23
	> Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти? А ты думал, штуки типа SIGSEGV из воздуха чтоли материализуется? А вот и хрен, это проц аппаратное исключение кинул на самом деле. > Речь про кучу, если вдруг проблемы с чтением В ней в конечном итоге тоже - память либо выделят, либо при левых поползновениях SIGSEGV будет. На самом деле в линухе при оверкоммите (т.е. по дефолту) это не сильно лучше стека ибо де факто аллокация "виртуальная" и ничем не обеспечена. Реальное выделение только при обращении. Связано с тем что многие программы заказывают намного больше памяти чем реально юзают, и это позволяет на доступном RAM нафоркать сильно больше процессов, соответственно. Ценой некоей утратой предсказуемости - ибо ежели страница понадобилась - но ее нет - у вас *alloc вроде прокатил но это как бы и не обеспечено и нате-ка вам SIGSEGV. Но на внутренности кернела это не распостраняется. > Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны > железа самая топорная У heap и такой нет - поэтому аллокации и деаллокации многократно тормознее.
	Ответить | Правка | Наверх | Cообщить модератору

	426. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 22:45
	> Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти? А ты думал, штуки типа SIGSEGV из воздуха чтоли материализуется? А вот и хрен, это проц аппаратное исключение кинул на самом деле. > Речь про кучу, если вдруг проблемы с чтением В ней в конечном итоге тоже - память либо выделят, либо при левых поползновениях SIGSEGV будет. На самом деле в линухе при оверкоммите (т.е. по дефолту) это не сильно лучше стека ибо де факто аллокация "виртуальная" и ничем не обеспечена. Реальное выделение только при обращении. Связано с тем что многие программы заказывают намного больше памяти чем реально юзают, и это позволяет на доступном RAM нафоркать сильно больше процессов, соответственно. Ценой некоей утратой предсказуемости - ибо ежели страница понадобилась - но ее нет - у вас *alloc вроде прокатил но это как бы и не обеспечено и нате-ка вам SIGSEGV. Но на внутренности кернела это не распостраняется. > Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны > железа самая топорная У heap и такой нет - поэтому аллокации и деаллокации многократно тормознее.
	Ответить | Правка | К родителю #326 | Наверх | Cообщить модератору

	533. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 16-Янв-24, 15:00
	>> Всего лишь 100Мб, не грохнется. > 1) Ну попробуй так на AtMega какой-нибудь :). Это и на AMD64 не работает.
	Ответить | Правка | К родителю #297 | Наверх | Cообщить модератору

	124. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (-), 15-Янв-24, 02:49
	> От переполнения стэка ни один код не защищён. И ни один код > не защищён от исчерпания памяти. Если я статически пишу 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. Просто крах без предупреждения, в рантайме, без возможности это обработать - может и ок для питоняш, но в системном яп - такое себе.
	Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

	138. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от jjklh (?), 15-Янв-24, 03:25
	>Просто крах без предупреждения, в рантайме, кто сказал раст?
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–2 +/–
	Сообщение от Аноним (149), 15-Янв-24, 03:28
	>Просто крах без предупреждения, в рантайме, без возможности это обработать - может и ок для питоняш, но в системном яп - такое себе. Сишечка не системная - также можно исчерпать стек, вызывая функции. Особенно если где-то там, в глубине вызовов, будет на стеке буфер, не VLA, но и не очень маленький - есть вероятность, что почти всегда из него будет использоваться пару байт, а иногда столько, что хватит для переполнения стека. VLA, конечно, усугубляет, но сишечка сама по себе неадекватна задачам сиспрога например.
	Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

	283. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 15-Янв-24, 13:29
	> Сишечка не системная - Да? А кто у нас тогда системный то? На сях что-то большая часть системщины, бутлоадеры, кернелы, фирмвари, либы, вот это все :). И у других - failure mode еще больше так то. В сях они простые и понятные как правило и их немного. > также можно исчерпать стек, вызывая функции. Особенно если > где-то там, в глубине вызовов, будет на стеке буфер, не VLA, > но и не очень маленький - Одна из причин по которым жирное использование стека в функциях считается чем-то нехорошим, и кернел собирается с варнингом на размер стекфрейма, если что. По моему если у функции стек более кило - нате вам варнинг, во! Кстати с современным компилером допустим сожрать стек рекурсией не так то просто, gcc допирает убрать сохранение-восстановление, копирование объекта и проч - и лианеризует рекурсивный вызов до чего-то типа цикла, с потреблением стека O(1) и временем выполнения O(n). И вот я вкатил рекурсию чтобы проверить работает ли мой детект stack overflow на мк и.. это не падает?! Ах ты ж блин, какой умный компилер! А чо, ассемблерщики, сможете оптимизнуть так же? :) > есть вероятность, что почти всегда из него будет использоваться пару байт, а иногда > столько, что хватит для переполнения стека. Поэтому... 1) Там где это важно чекают stack usage функций. 2) MISRA запрещает рекурсивные вызовы например, и системный софт должен намотать на ус эту идею и так не делать. > VLA, конечно, усугубляет, но сишечка сама по себе неадекватна задачам сиспрога например. Ну вы то нам покажете что-то лучше? А то уж рекурсию можно на чем угодно, даже на асме, и тот кстати без оптимизаций - не будет линеаризовывать рекурсивный вызов до более плоского цикла и там все грохнется куда охотнее :)
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (140), 15-Янв-24, 03:29
	В некоторых компиляторах есть builtin, позволяющий проверить наличие места на стеке. Где нет - его можно сделать. По-хорошему должен быть вариант alloca с проверкой. Но нет. По-хорошему должен быть VLA с проверкой на успех. Но Си - это не раст.
	Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

	292. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 15-Янв-24, 13:50
	> В некоторых компиляторах есть builtin, позволяющий проверить наличие места на стеке. Где > нет - его можно сделать. По-хорошему должен быть вариант alloca с > проверкой. Но нет. По-хорошему должен быть VLA с проверкой на успех. Просто вопрос был почему VLA не рекомендуют в системщине. Ну вот потому. В сях вообще нет ни слова про "stack" в спеках. И, в принципе, VLA не обязан жить именно в стеке. Однако проблема того что память не бесконечная а какая-то реакция на ее нехватку невозможна - остается в любом случае. > Но Си - это не раст. Что-то мне подсказывает что у хруста других failure modes - на десяток си хватит. Они вон там свой panic любимый едва законопатили, меняя чуть не сорц компилера аж когда оказалось что в ядре panic это не оч хороший способ реакции на нехватку памяти. Там же и сказочные костыли с try-вариантами конструкций. Господи, какой бастардизированый гибрид сей с которыми боролись и чего-от из плюсоты, все хучшее от обоих миров - в один яп?!
	Ответить | Правка | Наверх | Cообщить модератору

	375. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (375), 15-Янв-24, 18:48
	>VLA не обязан жить именно в стеке Локальные переменные живут в стеке. VLA в принципе может жить где угодно, но нужен он именно на стеке. >Они вон там свой panic любимый едва законопатили panic!ует код тогда, когда не обработана ошибка, в частности наиболее распространённый случай - когда на std::result вызывают unwrap. В системном кодe необработанных ошибок быть не должно - это путь либо к уязвимости, либо к kernel panic. rust это просто подсвечивает.
	Ответить | Правка | Наверх | Cообщить модератору

	429. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 23:02
	> Локальные переменные живут в стеке. VLA в принципе может жить где угодно, > но нужен он именно на стеке. Читайте стандарты си. Там вообще нет упоминания стека, никак и нигде. То что конкретные реализации решили делать так - ну, окей, однако если кто-то сделает это иначе, он - в своем праве. Это implementation defined хрень. Вы не можете уповать на это при написании программы. Поэтому если кто-то вывесит VLA через heap или что там у него - а они в своем праве были. У си довольно интересные стандарты - и далеко не всегда это именно похвала комитету. Спихнувшему более 9000 своих проблем на других. >>Они вон там свой panic любимый едва законопатили > panic!ует код тогда, когда не обработана ошибка, Я так понимаю что паника была дефолтовой реакцией на неуспешные потуги аллокации крупных массивообразных штук, box чтоли, они там называются. И дошли они в результате до костылирования с тем же названием с довеском try отличающим по поведению эту сущность. Я честно говоря не понял почему все так костыльно и почему они так героически заборов дракона вдруг заметили что без него что-то стало хреново - и немедленно превратились в еще более стремного на вид дракона. Пппростите, а чем ЭТО отличалось от *alloc и сотоварищи? Можне мне этот высококонцептуальный пируэт объяснить? В результате маркетинг оказался, как бы это, не совсем правдой. Ибо в итоге пришли к тому с чем боролись. Фэспалм. > в частности наиболее распространённый случай - когда на std::result вызывают unwrap. А в кернеле и вообще embedded, etc вот именно тот std вообще будет? Ибо врядли дефолтовый, из супер-дупер-либы на все оказии делает именно то что уместно делать в недрах кернела. И скорее всего подразумевает работу в нормальной ос. А что если этой нормальной ос еще нет?! > В системном кодe необработанных ошибок быть не должно - это путь либо к уязвимости, > либо к kernel panic. rust это просто подсвечивает. И я не понимаю почему в wannabe-системном яп потребовались вон те костылищи с отдельными сущностями. Появившимися вот именно после потуг в кернел влезть. И там аж компилер постоянно патчат под это все. Представьте себе что для написания кернела требовалось бы постоянно патчить GCC. Вы бы вообще смогли кернел написать в результате? Да и Торвальдс, пожалуй, тоже.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (149), 15-Янв-24, 03:41
	>Если я статически пишу uint8_t arr[10]; я имею основания полагать что это будет работать даже на микроконтроллере с склерозом вместо памяти, и если этот код вообще запустился то скорее всего работает до упора. Конечно, не будет. Во всех тестах в массив будут записаны 1-3 байта и они ничего не поймают, в продакшоне наконец-то в этот массив запишут из сети 10 байт, запись затрет канарейки и структуры планировщика FreeRTOS, лежащие прямо за концом стека, задача вместо паники зависнет и девайс ребутнется по ватчдогу.
	Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

	290. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 13:45
	> Конечно, не будет. Во всех тестах в массив будут записаны 1-3 байта > и они ничего не поймают, в продакшоне наконец-то в этот массив > запишут из сети 10 байт, запись затрет канарейки и структуры планировщика > FreeRTOS, лежащие прямо за концом стека, задача вместо паники зависнет и > девайс ребутнется по ватчдогу. Это всякие системные ламеры, обложивщиеся RTOS не поймают, у них "тойота" и получается. А я посмотрел на тойоту. Подумал. И теперь - даже на Cortex-M без MPU научился делать лэйаут RAM где переполнение стека хоть на байт немедленно эскалирует в HARD FAULT (нет, не MPU, его нет), который не заметить очень сложно. Ибо самый суровый эксепшн на все ядро, выбивающий все кроме NMI нафиг. И теперь мы займемся реакцией на вот это, зная что в системе Ж, ждать вачдог не обязательно. ...а еще я таки сделал обработчикам приватный стек, так что они еще и что-то сделать могут. Даже если основной стек кончился. У ARM для этого довольно клевая фича есть, отдельный стек для handlers. ...кроме того я заинструментил немного наколенный, но весьма забавный анализ worst-case рантайм потребления стека. Идея проста: заполняем раму паттерном в startup, пускаем фирмвару работать, если знаем самые ресурсоемкие ветки, прозваниваем их. Через некоторое время просим дамп оперативы, смотрим на регион стека, делаем выводы о runtime margins.
	Ответить | Правка | Наверх | Cообщить модератору

	345. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 15-Янв-24, 16:42
	Главное, чтобы у тебя этот суровый(r) эксепшн(tm) не произошёл во время полёта на обоих модулях - основном и запасном...
	Ответить | Правка | Наверх | Cообщить модератору

	413. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от nothingaboutdog (?), 15-Янв-24, 20:45
	А как он может не произойти, если искандер-5 заходит на цель с перегрузкой в 30 раз больше, чем искандер-4 (и памяти для искандер-4 строго говоря не хватало, но с учетом ограничений ТТХ кулибины как-то зарелизились)???
	Ответить | Правка | Наверх | Cообщить модератору

	431. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 23:08
	> Главное, чтобы у тебя этот суровый(r) эксепшн(tm) не произошёл во время полёта > на обоих модулях - основном и запасном... Если это важно - это решается другими методами. См. как это кажется, боинг сделал. Две тимы писали 2 разные программы, запущенные на 2 разных процах, ... вот как раз чтобы вероятность этого была ниже плинтуса. ...у меня, к счастью, не настолько крутые требования, и все же мне охота залезть в довольно требовательные применения, где факап управления может чего-нибудь пожечь и проч, что как бы не прикольно. В этом смысле fail fast с приведением системы в безоапсное состояние лучше чем ждать вачдога в абы каком состоянии, делая хзчто.
	Ответить | Правка | К родителю #345 | Наверх | Cообщить модератору

	503. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 16-Янв-24, 11:27
	Не гидравлический пресс надеюсь? А то fail fast может в fall fast перейти :D
	Ответить | Правка | Наверх | Cообщить модератору

	504. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 16-Янв-24, 11:28
	Мне у некоторых софтсвитчей вот этот fail fast нравится. Да пусть оно лучше сессию дропнет, наплюёт херни в логи, или выдаст в сессию шум океанов марса. Нежели все 100500 звонков разом лягут.
	Ответить | Правка | К родителю #431 | Наверх | Cообщить модератору

	677. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 21-Янв-24, 20:56
	> Мне у некоторых софтсвитчей вот этот fail fast нравится. > Да пусть оно лучше сессию дропнет, наплюёт херни в логи, или выдаст > в сессию шум океанов марса. > Нежели все 100500 звонков разом лягут. Софт свич несколько отличается от печатки с силовухой, допустим. Одно дело по превышению тока сразу в safe state свалить, и совсем другое - подождать вачдога, который там дескать может ребутнет, но до того момента - силовые ключи - и половина платы - правратятся в чуть ли не кусок плазмы уже, и тогда х... толку с вачдога?! Даже если проц и перезагрузится - то чего? В этот момнет уже поздняк на превышение тока реагировать и что-то выключать.
	Ответить | Правка | Наверх | Cообщить модератору

	680. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 21-Янв-24, 22:17
	Если у вас на плате нет защиты от превышения тока кроме софта - я вам очень сочувствую, и да, можно название, чтобы это не брать никогда?
	Ответить | Правка | К родителю #677 | Наверх | Cообщить модератору

	687. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 23-Янв-24, 22:14
	> Если у вас на плате нет защиты от превышения тока кроме софта По законам Мерфи - устройство порой сгорает первым, защитив предохранитель ;) И FYI, предохранитель нельзя брать впритык - иначе периодически его будет выбивать "без причины". А еще пусковые кратковременные режимы бывают куда тяжелее крейсерских. Это не значит что они вдолгую безопасны. Работает этот мир так. Но чтобы об этом знать надо немного поинженерить. Так что лишняя линия защиты никому не мешала еще. Алсо вылетевший предохранитель это прерывание сервиса, доволно надолго. Self restart после устранения проблемного условия - лучше чем трах с сменой предохранителя. По причинам выше - быстродействующий предохранитель, "на грани" - не захочется. Ибо придется постоянно заниматься его заменой. А то что медленный обгонит дестрой ключа крутым перегрузом... ну вот не факт. И вот там МК, которому микросекунды дом родной, имеет шансы зарубить проблемное условие ДО того как это станет проблемой. При том он в отличие от глупого предохранителя в курсе, startup это или авария, допустимо ли столько времени, или уже перебор, и так далее. И можно вон те неудачные соотношения несколько обойти. > - я вам очень сочувствую, и да, можно название, чтобы это > не брать никогда? ...сказал тип, стесняющийся уточнить название своего прова за отношение в ipv6 :). Впрочем можете не париться - я масспродом не занимаюсь и ваши шансы купить сие весьма низкие.
	Ответить | Правка | К родителю #680 | Наверх | Cообщить модератору

	688. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 23-Янв-24, 22:16
	А ваш софт умеет думать, пока МК дымится вместе с платой? :)
	Ответить | Правка | К родителю #687 | Наверх | Cообщить модератору

	689. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 23-Янв-24, 22:32
	Почему? Потому что по законам Мерфи первым сдохнут датчики для вашего софта.
	Ответить | Правка | К родителю #687 | Наверх | Cообщить модератору

	358. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (341), 15-Янв-24, 17:59
	Как я понял твои ответы. - Если мы используем массив со статическим временем жизни, то мы надеемся, что стек не переполнится. - Если мы используем обычный массив на стеке, то мы надеемся, что стек не переполнится. - Если мы используем VLA-массив, то много энергично говорим и надеемся, что стек не переполнится.
	Ответить | Правка | К родителю #290 | Наверх | Cообщить модератору

	434. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 23:21
	> Как я понял твои ответы. > - Если мы используем массив со статическим временем жизни, то мы надеемся, > что стек не переполнится. И мы можем более адекватно эту идею проверить. Частично даже в компилтайме, смотрением на размер стекфрейма. > - Если мы используем обычный массив на стеке, то мы надеемся, что > стек не переполнится. Это допущение опять же более просто проверить, если нет рекурсии. > - Если мы используем VLA-массив, то много энергично говорим и надеемся, что > стек не переполнится. VLA - это еще хуже чем динамическая аллокация памяти. Потому что это та же динамическая аллокация памяти - но еще и без возможности сделать что-либо осмысленное, и без известного на момент компила upper bound что вообще совсем рубит любой компилтайм анализ этого. Вы вообще не знаете worst case размер стекфрейма этой функции теперь. И таки си - мультипарадигменный. Если ну вот капец как надо - можно сделать "fully static allocation", распределив вообще все статически. Ну то-есть все переменные сделать либо static в функциях, либо глобальными. И тогда - если все выделено сразу на старте, оно не может закончиться вот хоть как. Единственное что остается это глубина вложенных вызовов функций. Это неоптимально по ресурсам - потому что все и вся выделено всегда. Зато гарантии лучше. Вот и выбирайте. Примерно такой же tradeoff существует и в оверкоммите памяти в случае линуха. Можете не оверкомитить и обеспечивать все выделеные адреса физической оперативой. Но тогда сможете намного меньше программ на том же RAM запускать.
	Ответить | Правка | Наверх | Cообщить модератору

	462. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (341), 16-Янв-24, 01:39
	Я почему шучу про "много энергично говорим" - потому что идеи assert'ов для размера VLA,  тестирования худшего случая отметаются как немыслимые и тебя куда-то совсем понесло. "Еще хуже чем динамическая аллокация памяти" - вот, фрагментация кучи уже лучше, чем VLA. Даже не "так же плоха", как написала бы MISRA, а хуже. > Это неоптимально по ресурсам - потому что все и вся выделено всегда В принципе на этот случай есть union'ы, но с ними придётся следить не за стеком, а за тем, чтобы не было обращений к неактивным полям и чтобы инициализация активного поля нигде не пропускалась.
	Ответить | Правка | Наверх | Cообщить модератору

	651. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 19-Янв-24, 19:38
	> Я почему шучу про "много энергично говорим" - потому что идеи assert'ов > для размера VLA,  тестирования худшего случая отметаются как немыслимые Не то что немыслимые - а "еще хуже чем динамическая аллокация". Ибо еще менее defined и еще меньше возможностей для корректной реакции. А что должен кернел сделать по assertion failed? В панику брякнуться? Ну, зашибись реакция, конечно. Юзерям понравится. Retry выделения в этой парадигме вообще не получится (смысл повторять тот же assertion?!), вернуть caller'у ошибку - наверное не assert тоже было. И получается как вон то - только еще хуже, ибо грабель больше и контроля над ручкой нет, грабля автоматически подпрыгивает и лупит в лоб всех кто проходит мимо. > и тебя куда-то совсем понесло. "Еще хуже чем динамическая аллокация памяти" - > вот, фрагментация кучи уже лучше, чем VLA. Внезапные крахи и почти полная невозможность их адекватного парирования спускают си до уровня питоняш и нафиг нам такой си вперся вообще? > В принципе на этот случай есть union'ы, но с ними придётся следить > не за стеком, а за тем, чтобы не было обращений к > неактивным полям и чтобы инициализация активного поля нигде не пропускалась. Я даже примерно так (изредка и немного) делаю - но при этом желательно сделать некий interlock ресурса, для проверки использования, иначе так окажется что мы тут храбро юзали массив - а вон там сетапнули DMA, забыли про это, все счастливо пахало... пока DMA не добрался до нас и не протер все к хренам другими данными... а мы не понимаем - откуда, блин, это вообще вот так?!
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от n00by (ok), 15-Янв-24, 06:49
	> От переполнения стэка ни один код не защищён. Дожили. А вот ядро Windows NT - защищено. Потому что там стек не используют и таких как ты не подпускают.
	Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

	227. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 15-Янв-24, 10:54
	Для особо одарённых, кто судит по себе и считает это троллингом: https://learn.microsoft.com/en-us/windows-hardware/drivers/k...
	Ответить | Правка | Наверх | Cообщить модератору

	509. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от freehck (ok), 16-Янв-24, 12:30
	> А вот ядро Windows NT - защищено. Потому что там стек не используют и таких как ты не подпускают. > Для особо одарённых, кто судит по себе и считает это троллингом: https://learn.microsoft.com/en-us/windows-hardware/drivers/k... И по ссылке написано, дословно, "под стэк выделено суммарно три страницы, так старайтесь делать дерево вызовов плоским, а рекурсивным вызовам поставьте ограничитель, потому что переполнение приведёт к фатальной ошибке системы".
	Ответить | Правка | Наверх | Cообщить модератору

	534. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 16-Янв-24, 15:13
	>> А вот ядро Windows NT - защищено. Потому что там стек не используют и таких как ты не подпускают. >> Для особо одарённых, кто судит по себе и считает это троллингом: https://learn.microsoft.com/en-us/windows-hardware/drivers/k... > И по ссылке написано, дословно, "под стэк выделено суммарно три страницы, так > старайтесь делать дерево вызовов плоским, а рекурсивным вызовам поставьте ограничитель, > потому что переполнение приведёт к фатальной ошибке системы". Надо перевести на понятный? Стек крайне осторожно используется для хранения адресов возврата, ни слова про размещение там array, а тем более variable length.
	Ответить | Правка | Наверх | Cообщить модератору

	536. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от freehck (ok), 16-Янв-24, 15:27
	Боюсь, что это ты не понял. Данная статья просто предостерегает разработчиков о том, что стек имеет весьма ограниченный размер, и даёт указания, как с ним следует работать. Ни о какой защите речи не ведётся. Это самый обычный стек.
	Ответить | Правка | Наверх | Cообщить модератору

	550. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от n00by (ok), 16-Янв-24, 16:10
	Очевидно, это ты не понял смысл "таких ... не подпускают". Защита стека в Windows выполняется административными методами. И вот таких, кто ничего не написал под ядро, но чему-то учит относительно стека, там не подпускают тоже.
	Ответить | Правка | Наверх | Cообщить модератору

	553. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от freehck (ok), 16-Янв-24, 16:27
	> Защита стека в Windows выполняется административными методами. Ух едрить как же всё запущено. Ну, с тем же успехом можно сказать, что код защищён от багов, потому что все MR-ы проходят обязательный code review. =) Зачёт, нуби. Завести что ли где-нибудь на опеннете мемориз с глупостями... =)
	Ответить | Правка | Наверх | Cообщить модератору

	564. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 16-Янв-24, 17:45
	>> Защита стека в Windows выполняется административными методами. > Ух едрить как же всё запущено. Ну, с тем же успехом можно > сказать, что код защищён от багов, потому что все MR-ы проходят > обязательный code review. =) > Зачёт, нуби. Завести что ли где-нибудь на опеннете мемориз с глупостями... =) Я знаю, что некоторые умело подменяют тезис с целью превзойти собеседника. Вот только я не спорю, а сообщаю факт: вопросом про стек отсеивают всех умельцев работать лишь языком, в самом начале собеседования.
	Ответить | Правка | К родителю #553 | Наверх | Cообщить модератору

	637. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (637), 19-Янв-24, 00:04
	Размер стека можно задать каким нужно, вызвав соответствующую функцию. Это он по-умолчанию такой, потому что "12 килобайт хватит каждому". А кому не хватит - тот может затребовать больший.
	Ответить | Правка | Наверх | Cообщить модератору

	641. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 19-Янв-24, 14:58
	> Размер стека можно задать каким нужно, вызвав соответствующую функцию. Формулировка некорректна. Можно _попробовать_ задать размер. KeExpandKernelStackAndCallout ... Returns success if the stack allocation is successful and the callout has been called. Otherwise, returns a failure status. > Это он по-умолчанию > такой, потому что "12 килобайт хватит каждому". А кому не хватит > - тот может затребовать больший. А кому в итоге не хватит? Running out of kernel stack space causes a fatal system error. Therefore, it is better for a driver to allocate system-space memory than to run out of kernel stack space. Если даже до этого не дочитали, то до описания KeExpandKernelStackAndCallout и понимания, зачем она вообще нужна, тем более не дошло.
	Ответить | Правка | К родителю #637 | Наверх | Cообщить модератору

	251. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _kp (ok), 15-Янв-24, 12:17
	> не защищён от исчерпания памяти. >> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000. Хорошо, n=55666, но память процесса переполнена. Или переполнена иным, более естественным способом. Что сделает ПО безопасном языке? Да точно так же грохнется,толко некролог подробнее выдаст, но это не точно. Во встраиваемом ПО можно генерировать прерывания, при попытке выхода за границы области стека или его части, но не везде это делается очевидным и удобным способом. Но и тут, по исчерпании памяти можно только перезапустить ПО, максимум с частичным сохранением состояния.
	Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

	295. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 15-Янв-24, 14:00
	>> не защищён от исчерпания памяти. >>> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000. > Хорошо, n=55666, но память процесса переполнена. > Или переполнена иным, более естественным способом. Я знаю что сделает нормальный системщик. 1) Запретит такую конструкцию если без нее можно обойтись. 2) Если нельзя, аллоцирует динамически - и проверит успех. А если неуспех, что-то сделает по этому поводу, от вываливания из программы до retry через некоторое время в надежде что память освободилась (так например некоторые БД делают, вместо того чтобы сразу завернуть, предпринимают несколько попыток, и сдаются только если за энное время не полегчало). > Во встраиваемом ПО можно генерировать прерывания, при попытке выхода за границы области > стека или его части, В обычных программах примерно то же самое известно как какой-нибудь SIGSEGV и в POSIX эта модель по сути и остается. Проц получает исключение от MMU, и кернел в общем то гейтует его программе как сигнал SIGSEGV. Дефолтный хэндлер просто вырубает прогу, но можно и свой прицепить и сделать что-то более продвинутое. Однако если вам приехал fault handler по причине "стек кончился" - ну, э, удачи в корректном возобновлени работы программы. Ведь стека уже не хватило, состояние в "основном потоке" в общем то уже урыто. Корректного гарантированого способа вернуться их хэндлера в основную тушку на этот момент уже не существует в общем случае. > Но и тут, по исчерпании памяти можно только перезапустить ПО, максимум с > частичным сохранением состояния. Окончание стека это весьма грубый системный факап. Ведуший к очень голимым последствиям. Тойота проверяла. Получив class action lawsuit от злющих родственников усопших водил и тех кому острые ощущения от вождения не понравились.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от n00by (ok), 15-Янв-24, 06:48
	> А в чём проблема VLA? Лучше с alloca и указателями для того > же самого геморроиться и статическому анализатору палки в колёса ставить? Проблема в том, что это ядро. Вот скажи, какой там размер стека?
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

24. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
Сообщение от Аноним (173), 14-Янв-24, 22:21
Ну если хруст завозят, то и православные плюсики должны завезти.
Ответить | Правка | Наверх | Cообщить модератору

	348. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от PnD (??), 15-Янв-24, 17:00
	Немного не так. Зашкварился на rust? Всё, теперь c++ отказать — не по понятиям. (Далее, остальные в очередь.) </trollFace>
	Ответить | Правка | Наверх | Cообщить модератору

	398. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от warlock66613 (ok), 15-Янв-24, 20:02
	Это уже помойка будет какая-то.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

25. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–9 +/–
Сообщение от Bottle (?), 14-Янв-24, 22:24
Плюсы очень нужны в ядре, потому что поддержка модулей в Си даже не планируется, а хедеры очень сильно замедляют компиляцию.
Ответить | Правка | Наверх | Cообщить модератору

	74. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (75), 15-Янв-24, 00:01
	Модули в рабочем состоянии пока что только в компиляторе от микрософта
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (98), 15-Янв-24, 01:25
	В шланге давно в рабочем состоянии. И в CMake с недавнего времени. Но ядро Linux продолжает жрать makefile-кактус вместо CMake+Ninja.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (115), 15-Янв-24, 02:20
	CMake сам по себе кактус. И у тебя вообще хватает инженерного интеллекта, чтобы догадаться, что система сборки, полностью заточенная под юзерспейс, для ядра не подходит?
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (140), 15-Янв-24, 03:30
	Сфигали не подходит для ядра, если для сборки под голые микроконтроллеры без разделения на юзерспейс и кернелспейс подходит?
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (115), 15-Янв-24, 05:25
	Если не подходит, то это же ещё не означает, что не найдутся упоротоые, которые будут готовить из буханки белого троллейбус. Ну и сравнил, конечно, гогнокод под голый контроллер с развесистым ядром.
	Ответить | Правка | Наверх | Cообщить модератору

	411. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 20:42
	Но, но ведь троллейбус делается из буханки ржаного! В любом случае чистые make файлы это уже анахронизм (кроме некрофагов из ядра)))
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–2 +/–
	Сообщение от Аноним (-), 15-Янв-24, 00:47
	модули - проприетарный рак от майкрософт. хидеры ничего не замедляют, если мозгами хоть иногда пользоваться, что в случае майкрософт невозможно
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	159. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (115), 15-Янв-24, 05:26
	Тогда вам стоит для начала поработать с большими проектами
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (172), 15-Янв-24, 07:41
	Насколько большими? Сколько строк?
	Ответить | Правка | Наверх | Cообщить модератору

	303. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 15-Янв-24, 14:31
	Настолько, что какой-нибудь sloccount не посчитает за разумное время
	Ответить | Правка | Наверх | Cообщить модератору

	250. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (194), 15-Янв-24, 12:06
	так вы не делайта свои "большие" проекты в одну портянку....
	Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

	287. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (293), 15-Янв-24, 13:42
	А модули в Python, D и ещё много где, тоже Microsoft ввела?
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

	299. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (299), 15-Янв-24, 14:26
	header-only библиотеки конечно можно написать так, чтобы они замедляли компиляцию. но так обстоит дело с чем угодно почти. так что просто нужно писать грамотно и ничего замедлятся не будет. такая байка, что компиляция будет очень долгой из-за ho пошла еще со времен кода в духе александреску. ситуация уже давно изменилась а байка осталась.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	377. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (375), 15-Янв-24, 18:50
	Это не байка. Ты на своей шкуре это сможешь заценить, подключив в программу CLI11.
	Ответить | Правка | Наверх | Cообщить модератору

	418. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Bottle (?), 15-Янв-24, 21:24
	Это не байка. Погугли патчи ядра от Инго Молнара.
	Ответить | Правка | К родителю #299 | Наверх | Cообщить модератору

33. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
Сообщение от Ivan7 (ok), 14-Янв-24, 22:36
Наконец-то С++! Архаика Си - это конечно круто, но технологии идут вперёд!
Ответить | Правка | Наверх | Cообщить модератору

	183. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Герман (??), 15-Янв-24, 08:51
	Внедрение плюсов - такой себе шаг вперед
	Ответить | Правка | Наверх | Cообщить модератору

	537. Скрыто модератором	+/–
	Сообщение от Аноним (-), 16-Янв-24, 15:29
	Си плюс-плюс - это шаг назад.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

35. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
Сообщение от Аноним (35), 14-Янв-24, 22:40
Пусть пихают и раст и зиг и сипипи сразу. И вейланд с системдой тоже сразу в ядро. Ресукликс-Биникс!
Ответить | Правка | Наверх | Cообщить модератору

37. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
Сообщение от Аноним (37), 14-Янв-24, 22:44
И Carbon, и VLang - тоже !
Ответить | Правка | Наверх | Cообщить модератору

	59. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (58), 14-Янв-24, 23:39
	Cabron.
	Ответить | Правка | Наверх | Cообщить модератору

	276. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (293), 15-Янв-24, 13:23
	Cartoon
	Ответить | Правка | Наверх | Cообщить модератору

	327. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Котофалк (?), 15-Янв-24, 15:35
	а вот VLang мысль и в самом деле интересная. Но, но что там с архитектурами, отличными от x86?
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	498. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (499), 16-Янв-24, 10:52
	Он вроде в С компилируется, значит считай поддерживает считай что все. В отличии кстати от очень ограниченного набора платформ у Rust.
	Ответить | Правка | Наверх | Cообщить модератору

39. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
Сообщение от Аноним (37), 14-Янв-24, 22:46
Не забывая про Zig и Seed   (ElenaLang -тоже неплохо )) )
Ответить | Правка | Наверх | Cообщить модератору

	300. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Sw00p aka Jerom (?), 15-Янв-24, 14:26
	Marusya на подходе :)
	Ответить | Правка | Наверх | Cообщить модератору

	324. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 15:30
	Сначала Алиса
	Ответить | Правка | Наверх | Cообщить модератору

	333. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Sw00p aka Jerom (?), 15-Янв-24, 15:46
	> Сначала Алиса такими темпами не видать нам Katyusha :)
	Ответить | Правка | Наверх | Cообщить модератору

	409. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 20:35
	Seed это вот этот https://ru.wikipedia.org/wiki/Seed7 ?
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

42. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
Сообщение от Аноним (42), 14-Янв-24, 22:52
> Rust > C++ Бедный Linux, как же упорно туда всякую гадость пихают...
Ответить | Правка | Наверх | Cообщить модератору

	83. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+6 +/–
	Сообщение от Аноним (115), 15-Янв-24, 00:14
	Если плюсы таки завезут, то rust там быстро сдохнет
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+6 +/–
	Сообщение от Герман (??), 15-Янв-24, 08:52
	Вместе с Си и ядром целиком
	Ответить | Правка | Наверх | Cообщить модератору

	604. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (20), 17-Янв-24, 04:35
	Это тебе так кажется. Раст "пихают" не потому, что "фанаты", а потому, что на то есть объективные причины. Те самые причины, по которым пихают его, а не С++. Это не вопрос того, что кому больше нравится. Это вопрос сугубо технический. И раст чисто по техническим причинам оставляет С++ далеко позади.
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	624. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (623), 17-Янв-24, 17:06
	Да, конечно, не потому что 'фанаты'. Давай посмотрим на объективные факты. Основа современного софтверного мира прекрасно существуют вообще на Си, даже не на плюсах. Прекрсно существует несмотря на все проблемы с Си. И rust в этом существовании ничего не может радикально улучшить. А именно не снизит существенно человеко-часы на разработку, ни увеличит кол-во решаемых проблем вообще. Т.е. проблема будущего развития ядра никак не упирается в проблемы Си в ядре. Технические вопросы это можно ли, и как, занести c++/rust в ядро. А нужно ли уже вопрос экономический если рассматривать в объективной плоскости. Оценок, естественно, профита от внедрения никто не делает т.к. это сложно и в реальности вопрос сводится в экспертную плоскость на уровень личных мнений. Если сравнение Си против rust более-менее можно увести в пользу rust, то с псюсами так не получится. Потому что плюсы это сбалансированный ЯП, а rust смещает внимание только на решение одной пробемы и заносит много мусорных решений из функциональщины вроде всё в ЯП выражения вместо высказываний. Выбор rust именно фетиш на единственную фичу и вера в её полезность, тут и близко нет никакого объективного технического выбора. В таком выборе в приниципе нет ничего плохого. Плохое это, будущи гуманитарием, пробовать замаскировать свои предпочтения под некий объективный и технический выбор.
	Ответить | Правка | Наверх | Cообщить модератору

	670. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Илья (??), 20-Янв-24, 18:40
	Кресты это нехорошо. Одни и те же ошибки ошибки при завышенном чсв плюсовиков Не могу придумать никакой отрасли (кроме игр) где я бы согласился на плюсах проект начинать
	Ответить | Правка | Наверх | Cообщить модератору

43. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
Сообщение от Анонимбус 2000 (?), 14-Янв-24, 22:54
Поддерживаю данное начинание!
Ответить | Правка | Наверх | Cообщить модератору

44. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
Сообщение от Антонимусс (?), 14-Янв-24, 22:55
Это ядро уничтожит энтропия и тогда GNU Hurd всех победит. Осталось подождать ещё лет 10.
Ответить | Правка | Наверх | Cообщить модератору

45. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от Аноним (45), 14-Янв-24, 22:57
Хм, я от с/с++ отошел лет так 15 назад. Но вроде наибольшей проблемой в применении плюсов была бинарная несовместимость между разными компиляторами. Тогда как в чистом с можно было линковаться между разными компиляторами, потому что есть бинарная совместимость. Для расширений питона это вроде до сих пор актуально. Не будет ли из-за этого проблем с ядром? Гарантировать что все блобы в ядре и сторонние модули будут скомпилированы одним компилятором никто не может.
Ответить | Правка | Наверх | Cообщить модератору

	48. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (48), 14-Янв-24, 23:03
	Ведро беспокоит что-либо, кроме gcc?
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 14-Янв-24, 23:15
	А разве с СИ не так же? Пришлось делать гну-тые расширения, чтобы собирать ядро.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	57. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (57), 14-Янв-24, 23:33
	>Но вроде наибольшей проблемой в применении плюсов была бинарная несовместимость между разными компиляторами. Я до сих пор проигрываю с того, что они даже схему manglingа стандартизировать не могут.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	374. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 18:47
	Да чё там думать, пусть берут эту схему из g++. Кстати, кто-то как-то приводил документ из недр Мелкомягких, где они это и предлагали сделать на уровне языкового стандарта. Сейчас не могу найти ту ссылку.
	Ответить | Правка | Наверх | Cообщить модератору

	380. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (293), 15-Янв-24, 18:56
	Зачем конкретному ядру бинарная совместимость? Эту версию ядра или другую можно полностью с модулями пересобрать другой версией компилятора. Стороннние модули тоже можно пересобрать нужной версией. Про какие блобы речь? Если загружаемые прошивки в девайсы, то пофиг, чем оно там для них собиралось. Оно с кодом ядра линковаться и не будет. Если блободрайверы, так это же хорошо. Мейнтейнеры ядра и так всеми силами борются с блободрайверами. Это им только в помощь. Пусть вендоры приучаются выпускать открытые драйвера.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	416. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от ТвойКопетанОчевидность (?), 15-Янв-24, 21:05
	Например, какая-нибудь nvidia тебе поставляет драйвер готовым модулем
	Ответить | Правка | Наверх | Cообщить модератору

46. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–3 +/–
Сообщение от 3draven (ok), 14-Янв-24, 22:58
Скоро ядро перепишет ИИ. В бинарных кодах сразу.
Ответить | Правка | Наверх | Cообщить модератору

	50. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Информатика (?), 14-Янв-24, 23:18
	Машинный код
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 02:50
	Пусть хотя бы драйвер напишет рабочий. А потом сможет в нем баг поправить.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	263. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (263), 15-Янв-24, 12:54
	ИИ пока что даже простой код генерировать не научился. Если не считать измусоленные факторилы с фибонначи. Куда ему до ядра?
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

47. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
Сообщение от Аноним (-), 14-Янв-24, 23:00
Это не тот самый разраб из Интела, который прислал такой пачт, который даже не скомпилился? И бедяге пришлось выражаться %^!@$%, тк высказаться прямо он уже не может((( 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ообщить модератору

53. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–4 +/–
Сообщение от Ilya Indigo (ok), 14-Янв-24, 23:22
Ну наконец-то об этом заговорили!
Ответить | Правка | Наверх | Cообщить модератору

64. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от cheburnator9000 (ok), 14-Янв-24, 23:43
давно пора.
Ответить | Правка | Наверх | Cообщить модератору

65. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
Сообщение от anodymus (?), 14-Янв-24, 23:44
А я согласен на плюсы в ядре. Благодаря изменениям под встраиваемые системы там теперь можно исключения не использовать. И более строгая проверка типов чем в С. Плюс, выразительнее языковые конструкции можно делать. А Раст - это просто попытка корпорастов под себя "поляну" подмять. Они же, наверняка, весь это "хайп" вокруг языка и разводят за бабло. Чтобы потом одним прекрасным утром поставить специальный блоб (как пример) в зависимостях и никто никуда уже не слезет. И с упорностью осла лезут в проект в который их никто не звал, вместо того, чтобы свой делать и показать как надо. Инфоцыгане. У C++ хотя бы комитет стандартизации существует. Да, он тоже многими корпорастами спонсируется, но там тяжелее свою волю навязывать. Приходится уже договариваться.
Ответить | Правка | Наверх | Cообщить модератору

	87. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от asaaddxasaadd (ok), 15-Янв-24, 00:22
	А каких, собственно, корпорастов? Тех, которые GCC разрабатывают?
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (75), 15-Янв-24, 00:28
	В гугле забанили?
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (75), 15-Янв-24, 00:30
	https://isocpp.org/std/the-committee
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

	181. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (175), 15-Янв-24, 08:06
	Одни белые лица и в основном мужики, никакого диверсити.
	Ответить | Правка | Наверх | Cообщить модератору

	414. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (-), 15-Янв-24, 20:49
	Ты лучше посмотри где они работают) Сплошные майкрософты, гуглы и прочие корпорации. Так что, "что они скажут - так и будет".
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 02:49
	> Плюс, выразительнее языковые конструкции можно делать. С другой стороны понаделают "выразительных конструкций", а потом разгребать. В большом проекте с большим кол-вом участников чем прямолинейнее конструкции, тем лучше имхо.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	237. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от yet another anonymous (?), 15-Янв-24, 11:19
	Вот, ради интереса, поробуйте объяснить кому-нибудь (да хоть себе) как в Ядре списки и работа с ними сделаны. (это к "чем прямолинейнее конструкции, тем лучше").
	Ответить | Правка | Наверх | Cообщить модератору

	340. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (194), 15-Янв-24, 16:27
	вы точно программист ?
	Ответить | Правка | Наверх | Cообщить модератору

	631. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (631), 17-Янв-24, 17:42
	Ну тут надвое сказано... Что именно "разгребать"?? ООП для того и придумали, что сложность современных систем на порядки выше старых юниксовых пародий. Соотв. без хорошей декомпозиции и абстракций ничего надёжного ты не напишешь. Другой вопрос, что с ЛЮБЫМ ООП языком придётся тянуть и его рантайм (который просто нельзя выкинуть). И как рантайм одного модуля "дружить" с остальными? (включая ядерный) Вот где засада. На одном хелловорлде рантайм прекрасно работает. Но в сложной модульной системе - большой вопрос.
	Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

	633. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Янв-24, 02:46
	> ООП для того и придумали, > что сложность современных систем на порядки выше старых юниксовых пародий. Соотв. > без хорошей декомпозиции и абстракций ничего надёжного ты не напишешь. А причем тут ООП? Хорошую декомпозицию и абстракцию можно сделать без него: lisp и erlang как пример.
	Ответить | Правка | Наверх | Cообщить модератору

73. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от Аноним (-), 14-Янв-24, 23:58
> в случае языка С++ можно по частям переводить код с языка C, так как С-код можно компилировать как C++ скорее потому, что с++ - надстройка над с >  один из ключевых разработчиков ядра в компании Intel того самого intel, который патчи даже не компиляет перед отправкой?
Ответить | Правка | Наверх | Cообщить модератору

	278. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (278), 15-Янв-24, 13:25
	> скорее потому, что с++ - надстройка над с Пожалуйста, никогда не пишите код на C++. Вот из-за таких сишников, пищущих на "C с классами" у C++ плохая репутация.
	Ответить | Правка | Наверх | Cообщить модератору

	378. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (375), 15-Янв-24, 18:52
	Давайте классы на GовноObject делать, так определённо лучше!
	Ответить | Правка | Наверх | Cообщить модератору

	456. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от InuYasha (??), 16-Янв-24, 00:10
	как раз наоборот - современный ++ выглядит порой как несто среднее между растом и brainfuck.
	Ответить | Правка | К родителю #278 | Наверх | Cообщить модератору

	491. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (341), 16-Янв-24, 10:02
	>> скорее потому, что с++ - надстройка над с > Пожалуйста, никогда не пишите код на C++. Вот из-за таких сишников, пищущих > на "C с классами" у C++ плохая репутация. Не знаю насчёт этого, но от неполной совместимости с C у него репутация портится. Например, type punning через union зачем-то сделали UB. На практике этот приём в плюсах широко используется и если он вдруг где-то сломается, это будет проблемой скорее компиляторописателей, чем пользователей компилятора. Реальный результат изменения - плюсовики бегают и стращают друг друга неопределённым поведением на смех растовикам. Вот сейчас в компиляторах сломать не рискуют, а через 50 лет? То-то же! Но это настолько удобный приём, что UB здесь как первородный грех. Но программирование - не религия, чтобы заниматься догматическим внушением вины перед Комитетом. Может, ему лучше убрать из текста бесполезный де-факто несуществующий UB?
	Ответить | Правка | К родителю #278 | Наверх | Cообщить модератору

95. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
Сообщение от Аноним (95), 15-Янв-24, 01:14
Потом все равно на Carbon переписывать.
Ответить | Правка | Наверх | Cообщить модератору

	116. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (107), 15-Янв-24, 02:30
	А вот кстати про Carbon почти никто не пишет, а он развивается просто бешеными темпами. Так что может быть и не шутка.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 02:46
	> почти никто не пишет, а он развивается просто бешеными темпами Понятное дело, что если обратную совместимость не блюсти, то можно все менять как хочешь. Другой вопрос: вот раст в ядро завезут, должен же быть фриз на версию компилятора, чтобы каждый раз новое ядро не пересобирать новой версией компилятора раста.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (175), 15-Янв-24, 07:32
	И карго почти наверняка будет запрещено, а ведь это считай центральная фича языка.
	Ответить | Правка | Наверх | Cообщить модератору

	243. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от yet another anonymous (?), 15-Янв-24, 11:27
	В методичке написано, что это не часть языка и вы можете жить и без него. Но: таки да, r... тащат в ядро, чтобы оно паровозиком для cargo послужило. Без cargo цели достигнуты не будут.
	Ответить | Правка | Наверх | Cообщить модератору

	440. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 23:39
	> а ведь это считай центральная фича языка. Агаблин, обеспечивает вендорлок на гугл, амазон и майкрософт.
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	695. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от wyry (-), 20-Авг-24, 14:19
	У меня поменялось мнение по поводу Carbon: профитнее лучше изучить сами плюсы, чем внедрять левый язык. В C++ УЖЕ есть все инструменты чтобы писать простой и безопасный код, нужно лишь научиться и разработать хорошие гайдлайны для последователей, в этом значительно больше смысла, чем разработка очередного языка, как будто сейчас мало языков.
	Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

	404. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 20:21
	Гугель говорил, что Carbon будет собирать и код писанный для C++.
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

96. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от Аноним (96), 15-Янв-24, 01:18
Подскажите, это начало конца или второе рождение?
Ответить | Правка | Наверх | Cообщить модератору

	103. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от bulbasalo (?), 15-Янв-24, 01:44
	Время переходить на  NetBSD.
	Ответить | Правка | Наверх | Cообщить модератору

	280. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 13:26
	Если и переходить на то семейство, то уж на Стрекозу.
	Ответить | Правка | Наверх | Cообщить модератору

	630. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (631), 17-Янв-24, 17:39
	Почему не QNX? Minix? Да даже BeOS была бы куда лучшей альтернативой!
	Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

	245. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (245), 15-Янв-24, 11:32
	Это метастазы.
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	629. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (631), 17-Янв-24, 17:38
	Это конвульсии трупа :) Фактически уже понятно - как только "добрый диктатор" сдохнет, начнётся полный коллапс (не по этой причине, а тупо из-за бестолкового, монолитного, плохо спроектированного ведра). И на каком языке писать ведро вопрос уже стоять даже не будет.
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

108. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–8 +/–
Сообщение от Аноним (105), 15-Янв-24, 02:10
Я за ядро на Java. Заколебали уже. Там тоже синтаксис  аналогичный. И вообще все есть интернет. У них вон 8-я версия много лет в продакшене и жабомашина может запускать разные версии когда надо. Чего к плюсам привязались? Солянка - так солянка.
Ответить | Правка | Наверх | Cообщить модератору

	265. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от aaaaa (?), 15-Янв-24, 12:55
	с gc что будем делать?
	Ответить | Правка | Наверх | Cообщить модератору

	281. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 13:28
	А JVM под чем крутить?
	Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

	308. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (115), 15-Янв-24, 14:37
	Под lisp-машиной
	Ответить | Правка | Наверх | Cообщить модератору

	388. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 19:10
	А Lisp-машину на чём? Гусары, молчать!
	Ответить | Правка | Наверх | Cообщить модератору

	417. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 15-Янв-24, 21:06
	Так она уже машина. Или не знаешь что это такое? Тогда википедия в помощь
	Ответить | Правка | Наверх | Cообщить модератору

	593. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (589), 16-Янв-24, 23:31
	Пока это только умозрительная машина. Которую можно вертеть только на ...
	Ответить | Правка | Наверх | Cообщить модератору

	330. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Котофалк (?), 15-Янв-24, 15:39
	> Я за ядро на Java. Только на java-процессоре.
	Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

	384. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (293), 15-Янв-24, 19:03
	А Lisp-машину на чём? Гусары, молчать!
	Ответить | Правка | Наверх | Cообщить модератору

	515. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Советский инженер (ok), 16-Янв-24, 13:45
	на эмуляторе поверх явапроцессора
	Ответить | Правка | Наверх | Cообщить модератору

113. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–6 +/–
Сообщение от Аноним (113), 15-Янв-24, 02:20
Пока линуксом управляет один единственный до*боеб, способный забаррикадироваться в своих 80-ых, и единолично принимающий судьбоносные решения, вашему красноглазому сообществу никакой прогресс не грозит. Все вы так и будете сидеть в этом ~1%-ом дер*ме, и извергать желчь в сторону виндовс и прочих маков.
Ответить | Правка | Наверх | Cообщить модератору

	117. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (107), 15-Янв-24, 02:32
	Что бывает с модными-молодежными компаниями, лезущими поперед батьки в пекло, можно увидеть на примере Мозиллы.
	Ответить | Правка | Наверх | Cообщить модератору

	652. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 19-Янв-24, 19:59
	> Что бывает с модными-молодежными компаниями, лезущими поперед батьки в пекло, можно увидеть > на примере Мозиллы. Есть пример лучще - Fuchsia и ее "вот, мы, ща, на десктопы, столица миоа - в нью-васюки!". Вон там в соседней новости, где гранд-план по захвату мира кажется немного обломался.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+4 +/–
	Сообщение от Аноним (120), 15-Янв-24, 02:42
	>Все вы так и будете сидеть в этом ~1%-ом дер*ме, и извергать желчь в сторону виндовс и прочих маков. Загвоздка в том, что недолболюбам на маках и виндовс тоже прогресс не грозит, только если прогресс в принятии ректальных зондов в виде ИИ. Ну и при всем ужасе красноглазого ПО аналогов ему не предвидится.
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	372. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 18:44
	> Загвоздка в том, что недолболюбам на маках и виндовс тоже прогресс не > грозит, только если прогресс в принятии ректальных зондов в виде ИИ. Вас услышали! В новом нотпаде уже встроено. Он теперь поди по сети отсылает каждое нажатие клавиши с 100% легитимной отмазкой :). Вы же не могли жить без AI в нотпаде, правда?! :) > Ну и при всем ужасе красноглазого ПО аналогов ему не предвидится. Вон вам чудный новый нотпад от майкрософта. Зато глаза правильного цвета, и стыд их видимо не ест :)
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 02:43
	Посмотри вот это видео https://www.youtube.com/watch?v=YyRVOGxRKLg Торвальдс говорит за внедрения раста как раз из-за этого. Но лично он ему не нравится.
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	136. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–2 +/–
	Сообщение от Аноним (105), 15-Янв-24, 03:12
	Че ты несешь? Совет директоров даже если и принимает решения, то не о каждом элементе и в каждой крупной конторе есть жесткая иерархия. Это типо император мать их японии, а это простолюдин. Простолюдин императору нихрена указывать не может потому что лидер может быть только один. Вам дают кость из раста которую разумно можно использовать ради фич типа написания драйверов без ошибок в памяти. То что есть извращенцы которым так проще -хрен с ними. Но каждый червь со своими советами лезущий это не принятие важных решений. То что ты неспособен осилить хоть что-то не значит что кто-то есть твой не так чтобы зашифрованный мат. Черви ничего Линусу не докажут.
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	152. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
	Сообщение от Аноним (115), 15-Янв-24, 05:05
	Линус понимает как нужно вести такой проект, а ты нет. Сейчас практически весь серверный рынок линуксовый, все другие ~юниксы давно на обочине.
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	611. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Школьник (ok), 17-Янв-24, 09:18
	Потому что корпорации в эпоху Интернета быстро поняли, куда дует ветер, и решили скинуться человекочасами на разработку того, что само по себе уже не могло давать конкурентных преимуществ. Это и есть главная причина того, что Линукс взлетел. И уж точно не технологическое превосходство - до первой половины нулевых в бзде лучше было сделано почти всё, а про то, насколько лучше в это же время был солярис, даже и говорить особо не надо.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (75), 15-Янв-24, 05:22
	Один процент на десктопах, а не на серверах. И проблема не в ядре
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	187. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (187), 15-Янв-24, 09:00
	Типичный пример извергания желчи от не линуксоида, обвиняющего в этом других. Ничего нового.
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	264. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (264), 15-Янв-24, 12:54
	Форкни ядро и веди его в какое хочешь будущее.
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

119. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 02:42
Останавитесь!
Ответить | Правка | Наверх | Cообщить модератору

128. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 02:57
> Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра и не позволяет постепенно переписывать код (в случае языка С++ можно по частям переводить код с языка C, так как С-код можно компилировать как C++). В поддержку использования С++ в ядре также выступили Иржи Слаби (Jiri Slaby) из компании SUSE и Дэвид Хауэллс (David Howells) из Red Hat. Round 2... Fight! Как бы в отчасти правда, но и ложь тоже. Пустив С++ в ядро им надо будет рядом гайдлайнов накатать какие фичи использовать, а какие нет. Хотя вон гугл в хромиуме вроде смог. Но оно вам надо?
Ответить | Правка | Наверх | Cообщить модератору

	153. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (115), 15-Янв-24, 05:07
	Гайдлайны, внезапно, в ядре и для Си есть. Уровень обсуждений далёких от разработки людей.
	Ответить | Правка | Наверх | Cообщить модератору

	306. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 14:36
	Для с++ они увеличатся на порядок из-за возможных фич языка
	Ответить | Правка | Наверх | Cообщить модератору

	328. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (293), 15-Янв-24, 15:35
	Пусть определятся, какие фичи в ядре допустимы. По тем и пишут.
	Ответить | Правка | Наверх | Cообщить модератору

	356. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–2 +/–
	Сообщение от Аноним (115), 15-Янв-24, 17:56
	Если на десятичный порядок, то конечно же нет, добавятся пару новых страничек
	Ответить | Правка | К родителю #306 | Наверх | Cообщить модератору

	425. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+4 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 22:35
	> Если на десятичный порядок, то конечно же нет, добавятся пару новых страничек Вот дока по стилю С в ядре https://www.kernel.org/doc/html/v4.10/process/coding-style.html - в печати 21 страница А4 Вот для примера С++ https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines - в печати 679 страниц! С++ гугла https://google.github.io/styleguide/cppguide.html - 89 страниц. Chromium https://chromium.googlesource.com/chromium/src/+/refs/heads/... https://chromium.googlesource.com/chromium/src/+/refs/heads/... https://chromium.googlesource.com/chromium/src/+/refs/heads/... - вот тут 50 страниц Qt https://wiki.qt.io/Coding_Conventions https://wiki.qt.io/Qt_Coding_Style https://doc.qt.io/qt-6/best-practices.html Лень все расписывать, но видно невооруженным взглядом, что там явно не "пару новых страничек"
	Ответить | Правка | Наверх | Cообщить модератору

	436. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–2 +/–
	Сообщение от Аноним (341), 15-Янв-24, 23:29
	> Вот дока по стилю С в ядре "Табы это 8 пробелов..." > Вот для примера С++ "Нас не волнует низкоуровневые вещи вроде отступов, а ещё мы предлагаем вам библиотеку." > Qt *Что-то не тянущее на 21 страницу*
	Ответить | Правка | Наверх | Cообщить модератору

	443. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 23:50
	>> Вот дока по стилю С в ядре > "Табы это 8 пробелов..." >> Вот для примера С++ > "Нас не волнует низкоуровневые вещи вроде отступов, а ещё мы предлагаем вам > библиотеку." Мой оригинальный комментарий https://www.opennet.me/openforum/vsluhforumID3/132575.html#128 содержит слово guideline. Если https://www.kernel.org/doc/html/v4.10/process/coding-style.html мешает понятия code style и guideline, то я не виноват. Для примера гугл также делает. Смотри тогда с ним. Но я говорил именно про гайдлайн и для плюсов там сильно больше надо будет писать. Хотя бы имея ввиду сколько всего добавляется в новых стандартах. Для примера можешь посмотреть доку хромиумуа по ссылке выше.
	Ответить | Правка | Наверх | Cообщить модератору

	437. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (115), 15-Янв-24, 23:32
	Мозг вообще пробовал хоть немного подключать, когда писал всю эту чушь? Дока в ядре касается практически только оформления кода (CS), когда как документ от Страуструпа на кучу страниц небольшой учебник по c++ для двигающихся горизонтально. И если даже его нормально распечатаешь, а не как ты через бразуер с гигантским шрифтом, то не будет 700 страниц. 21 страница ядерного CS читается за пару минут потому что там на самом деле не 21 страница, по такой же причине. В гугловом CS много филовского п-жа с рационализайией, его не обязательно читать чтобы понять что от тебя нужно. CS в хроиуме и Qt как раз несколько страничные и, как в случае с ядерным CS, читаются за пару минут. Могу ещё подкинуть данные, например, по Яндексовому CS - тоже 2-3 страницы на 2-3 минуты чтения. Итого, какие выводы... 1. Типичные плюсовые CS на несколько страниц и на максимум 5 минут чтения 2. Объём CS выбирает проект и если тебе удалось найти неадекватов вроде гугла, то из этого не следует, что все CS по плюсам будут такими. Пытаешься натягивать единичный пример на все, когда даже твоя подборка показывает обратное.
	Ответить | Правка | К родителю #425 | Наверх | Cообщить модератору

	438. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 15-Янв-24, 23:33
	^  Так и не понял куда приклеился ответ, он был анониму с ссылками
	Ответить | Правка | Наверх | Cообщить модератору

	441. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 23:45
	>[оверквотинг удален] > горизонтально. И если даже его нормально распечатаешь, а не как ты > через бразуер с гигантским шрифтом, то не будет 700 страниц. 21 > страница ядерного CS читается за пару минут потому что там на > самом деле не 21 страница, по такой же причине. > В гугловом CS много филовского п-жа с рационализайией, его не обязательно читать > чтобы понять что от тебя нужно. CS в хроиуме и Qt > как раз несколько страничные и, как в случае с ядерным CS, > читаются за пару минут. Могу ещё подкинуть данные, например, по Яндексовому > CS - тоже 2-3 страницы на 2-3 минуты чтения. Итого, какие > выводы... Ну ты к Яндексовому стилю не забудь прикрепить гайдлайн по использованию кода из аркадии взамену стд, если он, конечно, есть. > 1. Типичные плюсовые CS на несколько страниц и на максимум 5 минут > чтения Помимо CS есть guideline. Я писал именно про guideline, а не про правила расстановки пробелов и скобок. > 2. Объём CS выбирает проект и если тебе удалось найти неадекватов вроде > гугла, то из этого не следует, что все CS по плюсам > будут такими. Пытаешься натягивать единичный пример на все, когда даже твоя > подборка показывает обратное. У гугла как раз норм описано. Просто другие это не описывают, а потом вынужден на кодревью править "вот это мы не используем", "так мы не делаем". Конкретно, в хромиуме, одну и ту же вещь можно сделать по разному, используя как std так и тамошний base. Можно, конечно, жить с херовой вики (как в Я) и пинать всех на ревью, а можно нормально описать.
	Ответить | Правка | К родителю #437 | Наверх | Cообщить модератору

	466. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 16-Янв-24, 02:03
	> Ну ты к Яндексовому стилю не забудь прикрепить гайдлайн по использованию кода из аркадии взамену стд, если он, конечно, есть. Нет гайдлайна, раньше туда тупых не брали. Сейчас пытаешься приклеить документацию по внутреннему устройству проектов к CS по плюсам. Всё же давай начнёшь включать мозг, а? > Помимо CS есть guideline. Я писал именно про guideline, а не про правила расстановки пробелов и скобок. У Страуструпа на кучу страниц развёрнутый guideline, а всё остальное это в основном CS. Ну да, к Qt ещё приклеил документацию до внутреннему дизайну либ, вроде как у них устроены координатные сетки - вот это прямо таки самые настоящие СS и guideline-ы по С++ для Qt. Начни всё же включать мозг, если, конечно, он есть. > У гугла как раз норм описано. Просто другие это не описывают, а потом вынужден на кодревью править "вот это мы не используем", "так мы не делаем"... Чтобы рассказать как "мы (не) делаем" нужно просто рассказать "мы (не) делаем", а не тратить 80% от CS на трёп с размышлениями каким образом гугл докатился до такого CS-а. Ты же на ревью хочешь чтобы клиент просто затнулся и сделал как принято, а не рассуждал на тему верно это или нет? Потому у гугла CS построен неверно, его только спасает выделение рассуждений в визуально отдельный блок и опытный читатель может его пропускать. Тем более рационализация гугла во многих местах смехотворна, лучше бы просто написали ~ заткись и делай как тут показано. > Можно, конечно, жить с херовой вики (как в Я) и пинать всех на ревью, а можно нормально описать. Рассказываешь сказки с несуществующими проблемами. Таких проблем нет даже в проектах, где исторически в разных местах появились разные CSы. Типичному разработчику всё же хватает интеллекта посмотреть как было до и сделать аналогично.
	Ответить | Правка | Наверх | Cообщить модератору

	472. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 16-Янв-24, 02:32
	>> Ну ты к Яндексовому стилю не забудь прикрепить гайдлайн по использованию кода из аркадии взамену стд, если он, конечно, есть. > Нет гайдлайна, раньше туда тупых не брали. Просто в конторе не любят писать доку - признай это. Поэтому кичиться cs на 1 страницу не нужно. На самом много где не любят. Спорить на тему ее нужности и самодокументированного кода я не собираюсь:) >  Сейчас пытаешься приклеить документацию по > внутреннему устройству проектов к CS по плюсам. Совсем нет. Я вроде ясно выразился, что для C++ гайдлайны (не кодстайл) придется наисать гораздо больше чем для С. Вот это и нужно обсуждать. В качестве примеров я привел существующие документы проектов.   >> Помимо CS есть guideline. Я писал именно про guideline, а не про правила расстановки пробелов и скобок. > У Страуструпа на кучу страниц развёрнутый guideline, а всё остальное это в > основном CS. Ну да, к Qt ещё приклеил документацию до внутреннему > дизайну либ, вроде как у них устроены координатные сетки - вот > это прямо таки самые настоящие СS и guideline-ы по С++ для > Qt. Начни всё же включать мозг, если, конечно, он есть. Ты начинаешь порядком надоедать своей глупостью. По поводу qt есть страница про исключения https://doc.qt.io/qt-6/exceptionsafety.html Но ведь ты даже не удосужился прочитать. Если тебе это не нравится, то сравнивай с гугловским документом.   >> У гугла как раз норм описано. Просто другие это не описывают, а потом вынужден на кодревью править "вот это мы не используем", "так мы не делаем"... > Чтобы рассказать как "мы (не) делаем" нужно просто рассказать "мы (не) делаем", > а не тратить 80% от CS на трёп с размышлениями каким > образом гугл докатился до такого CS-а. Ты же на ревью хочешь > чтобы клиент просто затнулся и сделал как принято, а не рассуждал > на тему верно это или нет? Потому у гугла CS построен > неверно, его только спасает выделение рассуждений в визуально отдельный блок и > опытный читатель может его пропускать. Тем более рационализация гугла во многих > местах смехотворна, лучше бы просто написали ~ заткись и делай как > тут показано. Ну может у тебя есть ссылка на твой замечательный документ, который описывает как надо делать. Покажи его нам. >> Можно, конечно, жить с херовой вики (как в Я) и пинать всех на ревью, а можно нормально описать. > Рассказываешь сказки с несуществующими проблемами. Таких проблем нет даже в проектах, где > исторически в разных местах появились разные CSы. Типичному разработчику всё же > хватает интеллекта посмотреть как было до и сделать аналогично. Выше уже ответил по теме доке. Вижу, что проблема осталась.
	Ответить | Правка | Наверх | Cообщить модератору

	473. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 16-Янв-24, 02:41
	>> Ну ты к Яндексовому стилю не забудь прикрепить гайдлайн по использованию кода из аркадии взамену стд, если он, конечно, есть. > Нет гайдлайна, раньше туда тупых не брали. А в гугл берут тупых по твоей логике раз у них есть гайдлайн? Чтож тогда яндексоиды пулей летят в гугл к тупым как только получают офер?
	Ответить | Правка | К родителю #466 | Наверх | Cообщить модератору

	653. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 19-Янв-24, 20:02
	> А в гугл берут тупых по твоей логике раз у них есть > гайдлайн? Чтож тогда яндексоиды пулей летят в гугл к тупым как > только получают офер? Судя по ряду проектов гугли - и их участи - типа, вот, фуксии - похоже что берут.
	Ответить | Правка | Наверх | Cообщить модератору

	448. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 16-Янв-24, 00:00
	> Дока в ядре касается практически только оформления кода (CS), когда как документ от Страуструпа на кучу страниц небольшой учебник по c++ для двигающихся горизонтально. Оригинально я писал про гайдлайн, а не cs. Если ядро смешивает их, то ко мне какие вопросы. Вон гугл тоже смешивает, сравнивай с ним. > И если даже его нормально распечатаешь, а не как ты через бразуер с гигантским шрифтом, то не будет 700 страниц. 21 страница ядерного CS читается за пару минут потому что там на самом деле не 21 страница, по такой же причине. Ну выстави нужный шрифт и пришли результат. Мне влом этим заниматься. Но там явно не "на пару страничек больше". Можно хотя бы просто сравгить, что добавляет каждый новый стандарт С++ и С, и сделать из этого вывод о размере гайдлайна.
	Ответить | Правка | К родителю #437 | Наверх | Cообщить модератору

	468. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–2 +/–
	Сообщение от Аноним (115), 16-Янв-24, 02:13
	Выше рассуждаешь про вполне конкретную штуку - линуксовое ядро и c++ в нём. А значит и рассматривать должен ровно то, что там есть. Логично же, не так ли? > Можно хотя бы просто сравгить, что добавляет каждый новый стандарт С++ и С, и сделать из этого вывод о размере гайдлайна. Можно, но придётся опять включать мозг: большая часть изменений касается STL, которого в ядре не будет если туда завезут плюсы.
	Ответить | Правка | Наверх | Cообщить модератору

134. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
Сообщение от Аноним (-), 15-Янв-24, 03:04
AUTOBOT - это блочит (и я не знаю почему): А как они собираются исключения туда затянуть? (этого сделать вероятно не получится, да и не нужно) А без исключений затянут - это будет не C++, а просто "подмножество" C++ - типа "чуть улучшенный C". Ах да - это они всё ради темплэйтов наверное! P.S. А в Расте есть исключения?
Ответить | Правка | Наверх | Cообщить модератору

	154. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
	Сообщение от Аноним (115), 15-Янв-24, 05:08
	Разумеется, ведь самая главная фича плюсов это исключение
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Пряник (?), 15-Янв-24, 10:11
	Пока нашёл там обработку ошибок. То есть функция может вернуть либо результать, либо ошибку. И ошибка при этом вполне себе конретный тип данных, с которым можно дальше работать, например, завершив программу с сообщением или продолжить дальше работать, решив проблему.
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

147. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от Аноним (147), 15-Янв-24, 03:41
> Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра Это такой лол, что я даже не знаю, что сказать. Но когда пропадёт калабуховский дом, с рожей вонки буду сидеть.
Ответить | Правка | Наверх | Cообщить модератору

148. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
Сообщение от bOOster (ok), 15-Янв-24, 03:48
Здравый смысл, наконец-то берет верх..
Ответить | Правка | Наверх | Cообщить модератору

161. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
Сообщение от Аноним (96), 15-Янв-24, 05:49
Да уж, беда пришла откуда не ждали... Если что-то и может быть хуже С, то это С++.
Ответить | Правка | Наверх | Cообщить модератору

	176. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (172), 15-Янв-24, 07:46
	Поправил, не благодари > Да уж, помощь пришла откуда не ждали... Если что-то и может быть лучше С, то это С++.
	Ответить | Правка | Наверх | Cообщить модератору

168. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
Сообщение от n00by (ok), 15-Янв-24, 07:07
Единственная проблема плюсов в ядре -- это привычки и отношение к языку значительной части сишников. И вопрос тут не в том, кто прав, а кто нет. Люди годами писали ядро, потому их точка зрения имеет вес. Однако, после внедрения Rust этот аргумент превратился в тыкву.
Ответить | Правка | Наверх | Cообщить модератору

	370. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от ДаНуНафиг (?), 15-Янв-24, 18:36
	То, что будет возможность писать на плюсах совсем не означает, что толпы молодёжи (уже смешно) побегут яростно переписывать все ядро. Так что как пилили деды свою сишную часть, так и будут, пока (если) не будет вытеснена чем-то более актуальным.
	Ответить | Правка | Наверх | Cообщить модератору

	379. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (379), 15-Янв-24, 18:56
	Толпам молодёжи (и немоложёжи) вообще срать на ядро, они от него в принципе с удовольствием подальше держаться будут. Но не всегда есть такая опция. Драйвер сам не напишется... Нужен нормальный плюсовый фреймворк для драйверов.
	Ответить | Правка | Наверх | Cообщить модератору

	545. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 16-Янв-24, 15:47
	Под фреймворком обычно понимается что-то тяжёлое. На плюсах возможно реализовать библиотеку без лишних накладных расходов.
	Ответить | Правка | Наверх | Cообщить модератору

	543. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 16-Янв-24, 15:43
	На деле, плюсы в ядре повышают порог вхождения по сравнению с Си.
	Ответить | Правка | К родителю #370 | Наверх | Cообщить модератору

	638. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Гультай (?), 19-Янв-24, 09:03
	Лол, молодёжь на javascript пишет, ей что сишечка что плюсы это древние рукописи
	Ответить | Правка | К родителю #370 | Наверх | Cообщить модератору

178. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от freehck (ok), 15-Янв-24, 07:51
> Изначально тема разработки ядра на C++ была поднята в 2018 году инженером из Red Hat Это что, реклама Red Hat между делом? Данному разговору уже не первое десятилетие. > С инициативой продолжения обсуждения выступил Ганс Питер Анвин (Hans Peter Anvin) Сомневаюсь, что люди со стороны могут по предоставленному послужному списку оценить реальную авторитетность мнения данного разработчика. Напишите лучше новость, если Линус или Грег удостоят его мнение ответом. > Возможности, для которых ещё недавно приходилось привлекать специфичные GCC-расширения, теперь легко реализовать на стандартном C++ А актуален ли вопрос вообще? Недавно читал, что ядро нынче нормально собирается Clang-ом.
Ответить | Правка | Наверх | Cообщить модератору

	402. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от ИмяХ (ok), 15-Янв-24, 20:08
	>>ядро нынче нормально собирается Clang-ом. Это как раз именно потому, что в нём нет С++
	Ответить | Правка | Наверх | Cообщить модератору

182. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+6 +/–
Сообщение от Аноним (182), 15-Янв-24, 08:32
Я так подозреваю, что ядро на голой сишке писали, чтобы не было никакого неявного кода. По сути всем понятно, что любой ООП можно реализовать и без поддержки ООП в языке. На структурах и прописывая весь скрытый в ООП код ручками. Так возможно получится быстрее. Немного. Ну самый простой пример это managed строковые типы. Они безопаснее. Но они требуют динамического выделения памяти буквально на каждом шагу. А это на самом деле лишние тормоза. Чтобы не было никакого неявного тормозного кода - лучше юзать char*. Вы же знаете, что сегодняшних программистов учат в школе прогать на Питоне как обезьянок? Если им позволить юзать в ядре плюсы и stdlib - они ведь будут юзать самые тормозные конструкции, какие только можно. Они и PHP его бы на писали, если бы можно было.
Ответить | Правка | Наверх | Cообщить модератору

	185. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–2 +/–
	Сообщение от Аноним (36), 15-Янв-24, 08:55
	>По сути всем понятно, что любой ООП можно реализовать и без поддержки ООП в языке. Можно, но костыльно очень. Или хотите в ядро нечто, наподобие Glib? >На структурах и прописывая весь скрытый в ООП код ручками. Это человеконечитаемо, лапшакод. И зачем для каждого "класса" проделывать ручками одни и те же действия?
	Ответить | Правка | Наверх | Cообщить модератору

	220. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от n00by (ok), 15-Янв-24, 10:46
	Ядро писали на Си, потому что плюсов тогда толком и не было.
	Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

	329. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 15:37
	Ну были, конечно, уровня Borland C++. А вот был ли свободный g++ в 1991, не знаю.
	Ответить | Правка | Наверх | Cообщить модератору

	412. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от 22 (?), 15-Янв-24, 20:45
	Был где-то с 87-го: https://gcc.gnu.org/releases.html
	Ответить | Правка | Наверх | Cообщить модератору

	547. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от n00by (ok), 16-Янв-24, 15:56
	Гипотетически они может и были, а практически стандарт языка принят в 98-м.
	Ответить | Правка | К родителю #329 | Наверх | Cообщить модератору

	268. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от freehck (ok), 15-Янв-24, 12:57
	> Я так подозреваю, что ядро на голой сишке писали, чтобы не было никакого неявного кода. Никакого -- утверждение слишком сильное для сишки. Как минимум из-за неявного преобразования типов. Впрочем, по сравнению с крестами, я склонен согласиться: с крестами неявного кода было бы на порядки больше. > По сути всем понятно, что любой ООП можно реализовать и без поддержки ООП в языке. На структурах и прописывая весь скрытый в ООП код ручками. Я кстати пробовал так писать на сях. В силу их синтаксиса, к сожалению, получается весьма многословно, и работать с этим не так удобно, как хотелось бы. Впрочем, я склонен считать, что это проблема не собственно Си, а самой концепции ООП в целом. А так, как описываете Вы, ООП успешно добавляется в более высокоуровневые языки: Lisp-ы, ML-и, тот же Perl вон... То есть поинт тут в том, что так делать удобно только в случае использования языков более высокого уровня: причём крайне желательно, чтобы они обладали встроенными инструментами изменения своего синтаксиса. > Так возможно получится быстрее. Немного. Ну самый простой пример это managed строковые типы. Они безопаснее. Но они требуют динамического выделения памяти буквально на каждом шагу. А это на самом деле лишние тормоза. О том и речь: высокоуровневым языкам -- высокоуровневые задачи, и наоборот. > Вы же знаете, что сегодняшних программистов учат в школе прогать на Питоне как обезьянок? Если им позволить юзать в ядре плюсы и stdlib - они ведь будут юзать самые тормозные конструкции, какие только можно. Вот-вот. Тут та же логика, как когда тебя приглашает зайти на чай красивая девушка, но ты не идёшь, потому что она работает в стриптиз-клубе. В том смысле, что выбор инструмента -- это в частности вопрос социальный: архитектор смотрит не только на сам инструмент, но и на сообщество, которое вокруг инструмента сформировалось. И если сообщество ему не нравится -- то и инструмент выбран не будет. По части самого вопроса, тут на самом деле ни черта не ясно, зачем это нужно. Как бы, крестовики спокойно могут и на голом си написать модуль, если им потребуется, ибо всё-таки в некотором смысле одно является субсетом другого. Так и зачем тогда напрягаться, поддерживать какой-то дополнительный интерфейс? Статус-кво вполне удовлетворяет нуждам проекта.
	Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

	444. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от fuggy (ok), 15-Янв-24, 23:50
	Rust тоже не ООП язык. Вполне себе можно писать крупные проекты и в процедурном стиле, и в ООП, и в функциональном стиле. ООП переоценён, это не золотой молоток. А уж взглянув на Java Enterprise FizzBuzz страшно смотреть.
	Ответить | Правка | Наверх | Cообщить модератору

	470. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 16-Янв-24, 02:27
	В ООП стиле на расте писать нельзя т.к. нет наследования. ООП в самом деле не киллер фича, но на задачах, где оно нужно, без поддержки ООП тяжко
	Ответить | Правка | Наверх | Cообщить модератору

	478. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 16-Янв-24, 02:58
	> В ООП стиле на расте писать нельзя т.к. нет наследования. ООП в > самом деле не киллер фича, но на задачах, где оно нужно, > без поддержки ООП тяжко В каких задачах нужно ООП?
	Ответить | Правка | Наверх | Cообщить модератору

	497. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (499), 16-Янв-24, 10:45
	Тот же бизнес с иерархией документов, где каждый с небольшими отличиями, ролями. Медицина, эконометрика, области математики со сложным поведением объектов. Тысячи их.
	Ответить | Правка | Наверх | Cообщить модератору

	511. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от freehck (ok), 16-Янв-24, 13:05
	> Тот же бизнес с иерархией документов, где каждый с небольшими отличиями, ролями. > Медицина, эконометрика, области математики со сложным поведением объектов. Тысячи их. На самом деле ООП там нужен только потому, что ООП является отдельной индустрией-в-себе: это своя особая экосистема, свой собственный мир, у него свои разработчики, свои проблемы и своя головная боль. По существу, он нужен только там, где разработка уже в этой экосистеме живёт. Поскольку в высокоуровневых языках объекты первого порядка давно являются само собой разумеющимися вещами, то кроме выше названной социальной -- потребности в ООП-е как таковой нет: код на фанкторах пишется и понимается куда проще.
	Ответить | Правка | Наверх | Cообщить модератору

	594. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (589), 16-Янв-24, 23:45
	> код на фанкторах пишется и понимается куда проще. Если объекты (в плане понятий из предметной области) однотипные. Любая, даже минимальная, иерархия приводит к росту гемороя в геометрической прогрессии. Люди думают понятиями а не раздельно существующими матрицами свойств.
	Ответить | Правка | Наверх | Cообщить модератору

	694. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от freehck (ok), 25-Июн-24, 14:05
	> Люди думают понятиями а не раздельно существующими матрицами свойств. Что ближе к корове, трава или курица? Аналитик ответит, что курица, потому что они оба -- животные. Холист ответит, что трава, потому что корова её ест. Надо уметь думать и так, и эдак. Тезис о том, что "люди думают понятиями" -- это ошибка и одновременно оправдание, чтобы не осваивать мышление иного рода.
	Ответить | Правка | Наверх | Cообщить модератору

	332. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (115), 15-Янв-24, 15:43
	c++ это не либа работы со строками. Причины совершенно в ином - нет API и нет гарантий на оптимизации сахара. Тем более если ещё брать c++ образца начала 2000, то вообще ужасный ЯП с минимум оптимизаций сахара компилятором.
	Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

186. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
Сообщение от awoland (ok), 15-Янв-24, 08:59
Это у Red Hat всё шуточки первоапрельские, а между тем Эпол, например, вполне успешно и уже давно применяет Embedded С++ для написания системных Kernel extensions (драйверов) в ядре XNU для всей линейки своих OS (macOS, iOS, iPadOS & e.t.c.) ...
Ответить | Правка | Наверх | Cообщить модератору

	196. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Noname (??), 15-Янв-24, 09:50
	У эппла анально-ректальные стайлгайды и референсы. Во-вторых, эпплы сами выпускают железо и сами пишут под него. В отличии от линпус-зоопарка, у них чёткий список устройств, которые должны работать с теми или иными компонентами.
	Ответить | Правка | Наверх | Cообщить модератору

	210. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от beck (??), 15-Янв-24, 10:23
	Винда написана на С++ и работает на огромном зоопарке устройств.
	Ответить | Правка | Наверх | Cообщить модератору

	218. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (214), 15-Янв-24, 10:44
	Не такой уж и зоопарк, всего полтора типа железа, которое в ней поддерживалось изначально. Зато её в бсод отправляет и открытие ютуба в браузере и сохранение файла в блокноте, про регулярно разлетающиеся файловые таблицы можно не вспоминать. Показательный уровень.
	Ответить | Правка | Наверх | Cообщить модератору

	221. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (214), 15-Янв-24, 10:46
	Отличие кстати в том, что железо разрабатывают под ОС, потом костыляют адовые блобы с кучей костылей чтобы хоть как-то работало. В линуксе на помойные драйвера смотрят криво.
	Ответить | Правка | Наверх | Cообщить модератору

	225. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от beck (??), 15-Янв-24, 10:51
	Какие полтора типа? Минимум шесть. > её в бсод отправляет и открытие ютуба в браузере и сохранение файла в блокноте, про регулярно разлетающиеся файловые таблицы можно не вспоминать Windows не виновата в том, что у тебя лапки.
	Ответить | Правка | К родителю #218 | Наверх | Cообщить модератору

	232. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (214), 15-Янв-24, 11:01
	>Минимум шесть. Суть в том, что они там были испокон времён, ничего нового, и то на хлам с армом пришлось влить миллиарды миллиардов 15 лет назад, который всё равно оказался нежизнеспособным. >Windows не виновата в том, что у тебя лапки. Ну, тут виноваты windows update и неквалифицированные некомпетентные кадры в microsoft, не сама windows, понятное дело.
	Ответить | Правка | Наверх | Cообщить модератору

	485. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (482), 16-Янв-24, 06:52
	> Зато её в бсод отправляет и открытие ютуба в браузере и сохранение файла в блокноте, про регулярно разлетающиеся файловые таблицы можно не вспоминать. Показательный уровень. Выкинь уже свой зион с али, с «ECC»-памятью.
	Ответить | Правка | К родителю #218 | Наверх | Cообщить модератору

	488. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (214), 16-Янв-24, 09:45
	Твои фантазии унылые, фиксация какая-то?
	Ответить | Правка | Наверх | Cообщить модератору

	307. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от awoland (ok), 15-Янв-24, 14:37
	Во-первых, стайлгайды и референсы не имеют никакого отношения к технологиям программирования. Это чистая политика компании. Во-вторых, пример успешного написания кучи драйверов энтузиастами-хакинтошниками для железа, которого никогда отродясь не было в железе Эппле чётко доказывает, что и второй ваш довод является примером газификации луж...
	Ответить | Правка | К родителю #196 | Наверх | Cообщить модератору

	349. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Noname (??), 15-Янв-24, 17:03
	> хакинтошниками И ты ещё что-то там про газификацию луж пишешь? Лол.
	Ответить | Правка | Наверх | Cообщить модератору

188. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
Сообщение от poulch (??), 15-Янв-24, 09:09
Вообще вопрос надо ставить глобально. Зачем ограничения на язык для разработки модулей ядра? Далеко не всякие модули включаются в состав поставки ядра. Если так хочется, то пусть ядро и комплектные модули  будут на С, но сторонние разработчики должны иметь возможность писать на любых языках. Я 20 лет страдал как единственный разработчик на фирме. Либы для разных платформ на С++ с общим кодом практически, а с драйверами вечная боль С++ под вин и С под  линукс. причем лет 15 назад были патчи на ядро которые финские студенты написали емнип которые давали возможность собирать ядро с++ компилятором...
Ответить | Правка | Наверх | Cообщить модератору

	205. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (205), 15-Янв-24, 10:09
	Та же мысль. В Сишный интерфейс функций умеют почти все языки, пусть ядро остается на Си, а модули пишут кто на чем хочет.
	Ответить | Правка | Наверх | Cообщить модератору

	246. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Советский инженер (ok), 15-Янв-24, 11:35
	собственно, а кто запрещает?
	Ответить | Правка | Наверх | Cообщить модератору

	459. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (459), 16-Янв-24, 00:16
	Тогда как собирать всю эту мозаику? У инструментов будут свои зависимости, а у тех еще зависимости... А так-то я сам не против.
	Ответить | Правка | К родителю #188 | Наверх | Cообщить модератору

191. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
Сообщение от Аноним (191), 15-Янв-24, 09:23
Зачем? ибо когда придёт какой-нибудь С++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ообщить модератору

	229. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (459), 15-Янв-24, 10:58
	Наверное, разработчикам ядра Linux все же виднее, зачем им нужен C++ и почему Раст для них не подходит.
	Ответить | Правка | Наверх | Cообщить модератору

	284. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 13:34
	"Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра"
	Ответить | Правка | Наверх | Cообщить модератору

	595. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (589), 16-Янв-24, 23:48
	> какой-нибудь С++50, который наконец-таки превратится в Rust Ты думаешь, что в C++50 порежут все что можно по самые помидоры? Так что останется одна заготовка языка?
	Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

192. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
Сообщение от d_kazbek (?), 15-Янв-24, 09:40
давно пора
Ответить | Правка | Наверх | Cообщить модератору

193. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от Noname (??), 15-Янв-24, 09:43
Руст действительно будет интереснее, а кресты уже показали несостоятельность за годы существования. Когда-то думал, что взлетит D-шка, но увы.
Ответить | Правка | Наверх | Cообщить модератору

	233. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (459), 15-Янв-24, 11:01
	Интереснее побаловатся на раз, а так С++ зрелый язык промышленной разработки и продожает активно использоватся, особенно в коммерческой разработке.
	Ответить | Правка | Наверх | Cообщить модератору

	628. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (631), 17-Янв-24, 17:27
	А чем D не взлетел?! Что в этом языке такого плохого, что его нельзя использовать для ведра?
	Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

203. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от Tron is Whistling (?), 15-Янв-24, 10:07
Ну вообще плюсы в ядре - здраво, но с оговорками. Исключения придётся вымести, по понятным причинам. STL тоже придётся вымести, в основном из-за отсутствия единого аллокатора. С другой стороны, отсутствие STL кстати как раз отпугнёт целую массу тех, кто в не-плюсовый C не осилил.
Ответить | Правка | Наверх | Cообщить модератору

	239. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от ay8910 (?), 15-Янв-24, 11:22
	Какие ещё целые массы тех, кто в не-плюсовый C не осилил - как они вообще окозались в разработчиках ядра-Линукс ???
	Ответить | Правка | Наверх | Cообщить модератору

	271. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (253), 15-Янв-24, 12:58
	Человек не понимает, что ядро пишется корпорациями на деньги корпораций. Им и решать, какой язычок использовать, а какой - нет.
	Ответить | Правка | Наверх | Cообщить модератору

	320. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 15-Янв-24, 15:12
	Цель как раз в том, чтобы они в них и не оказались :)
	Ответить | Правка | К родителю #239 | Наверх | Cообщить модератору

	407. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 20:26
	Сходи к попам, посмотри на их кресты. Пойми, чем плюс отличается от креста.
	Ответить | Правка | К родителю #239 | Наверх | Cообщить модератору

	274. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 13:19
	Но какую-то лёгонькую реализацию STL для целей внутри ядра, всё же, не помешает. Например, Vector и Array - большая польза. Хотя бы, чтобы за пределы буфера не выходить.
	Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

	285. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (278), 15-Янв-24, 13:35
	> STL тоже придётся вымести, в основном из-за отсутствия единого аллокатора. Во всех контейнерах STL можно передавать собственные аллокаторы. Можно хоть для каждого аллокатора сделать свой набор классов, и это будет намного чище и безопасней дёрганий кошмарных malloc'ов и бесконечной ручной проверкой высвобождения всех сырых указателей. STL это вообще по большей части набор шаблонизированного кода, странно это не знать.
	Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

	319. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 15-Янв-24, 15:11
	Соглашусь только за C++20. Хотя да, в принципе о нём и речь.
	Ответить | Правка | Наверх | Cообщить модератору

	334. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 15-Янв-24, 15:47
	Вместо STL будет своя либа с примитивами в c++ стиле. STL для ядерных целей не подходит
	Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

208. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от Пряник (?), 15-Янв-24, 10:16
> Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра и не позволяет постепенно переписывать код Я, конечно, не участвую в разработке ядра и не мне решать (как и многим комментаторам тут), но синтаксис С++ будет в разы хуже, чем Rust. Но, к сожалению, ядро пилит кучка ретроградов-неосиляторов.
Ответить | Правка | Наверх | Cообщить модератору

	222. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–3 +/–
	Сообщение от banonymous (?), 15-Янв-24, 10:47
	Как раз неосиляторы и впариают новые языки. Писать на них они тоже не умеют, но в резюме такие детали можно упустить.
	Ответить | Правка | Наверх | Cообщить модератору

	256. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (253), 15-Янв-24, 12:42
	Впарили раст в ядро - корпорации, их ядро, а не неосиляторы. У корпораций нет интересов писать на сишке, потому что им, по их причинам нужен раст. А обычные любители будь-то сишки или раста ничего не решают.
	Ответить | Правка | Наверх | Cообщить модератору

	457. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (459), 16-Янв-24, 00:11
	Что-то по вакансиям не сильно этого заметно.
	Ответить | Правка | Наверх | Cообщить модератору

	493. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (253), 16-Янв-24, 10:13
	Какие такие вакансии? Ты о чём? Речь про ведро, корпорациям-хозяйкам ведра не нужны никакие вакансии, разрабы уже есть у них.
	Ответить | Правка | Наверх | Cообщить модератору

	282. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (278), 15-Янв-24, 13:28
	> синтаксис С++ будет в разы хуже > к сожалению, ядро пилит кучка ретроградов-неосиляторов И кто же это тут несолилятор, лол.
	Ответить | Правка | К родителю #208 | Наверх | Cообщить модератору

212. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
Сообщение от beck (??), 15-Янв-24, 10:24
Ядро windows написано на С++. Вопрос об использовании С++ давно закрыт. Это работает.
Ответить | Правка | Наверх | Cообщить модератору

	215. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Пряник (?), 15-Янв-24, 10:29
	Но даже windows переходит на Rust.
	Ответить | Правка | Наверх | Cообщить модератору

	230. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от beck (??), 15-Янв-24, 10:58
	В винде архитектура гибридная. Они могут позволить себе какие-то независимые части сделать на более других языках. Поэтому и С, и С++ и С#. И вот даже Rust. С линуксом и его монолитной архитектурою...
	Ответить | Правка | Наверх | Cообщить модератору

	339. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 15-Янв-24, 16:00
	Пиши драйвера в пр-ве пользователя на чём угодно
	Ответить | Правка | Наверх | Cообщить модератору

	234. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (459), 15-Янв-24, 11:08
	Не переходят, а пишут отдельные модули. Там же не идиоты переписывать работающий код в которй инвестированы миллионы.
	Ответить | Правка | К родителю #215 | Наверх | Cообщить модератору

	228. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (41), 15-Янв-24, 10:56
	> windows > работает Ну, работать та работает. Но вот как работает...
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

	231. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от beck (??), 15-Янв-24, 11:00
	Нормально работает. Десятки миллионов серверов и сотни миллионов десктопов по всему миру. Не говоря уже про например медицинскую технику, управлялки станками и прочие кошерные вещи.
	Ответить | Правка | Наверх | Cообщить модератору

	266. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (253), 15-Янв-24, 12:55
	по-дефолту в плюсах нет инструментов для безопасной работы с памятью. RAII и smart поойнтерс - это совсем недавно любители плюсов нашкрябали, плюсы - сплошной ансейф. УРА товарщи!
	Ответить | Правка | Наверх | Cообщить модератору

	364. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (115), 15-Янв-24, 18:26
	> RAII ... was developed for exception-safe resource management in C++ during 1984–89 Очнись, наркоша. Смарт поинтеры в плюсовых проектах уже более 30 лет в том или ином виде, до стандартного STLя доехали лет 13 назад.
	Ответить | Правка | Наверх | Cообщить модератору

	494. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (253), 16-Янв-24, 10:17
	Ну ты и оболтус. Ну так по дефолту усё это выключено, в опенсорсе твоё стл никто не пользует. Твои плюсеги - сплошной ансейф, а когда находятся cve в плюсовых опенсорсах - разрабы отвечают: ну я забыл заюзать эту фичу. Ахахаха, плюсовеки, такие плюсоеки.
	Ответить | Правка | Наверх | Cообщить модератору

	261. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (264), 15-Янв-24, 12:52
	Если так хорошо работает, почему везде линукс? Фактически сиплюсы используются только для игр. Винды - ось для запуска игр.
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

	288. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от beck (??), 15-Янв-24, 13:43
	Я прихожу к врачам, в мрт винда, на рентгене винда, в аппарате узи винда. Смартфон соединить с ноутом? Производители делают только для винды. Нормальный офис? Винда. Нориальный почтовый клиент с календарями, встречами и прочими плюшками? Опять винда. Управление зоопарком десктопов? Винда. Удалённый доступ с аппаратными ключами? Винда. 99% промышленных софтов, на которых работать можно, опять винда.
	Ответить | Правка | Наверх | Cообщить модератору

	312. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 14:55
	Не хочется тебя расстраивать, но это не от того, что винда хорошо работает. Это бизнес, ничего личного.
	Ответить | Правка | Наверх | Cообщить модератору

	336. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 15:55
	Причем тут бизнес если даже бизнес-линукс, типа шапки мимикрирует под винду? 2 самых распространенных DE копируют решения из МАС оси и винды. Или ты хочешь, чтобы бедный врач пердолился с гентой или другими маргинальными дистрами? Искал дрова к специфическому оборудованию типа ЭЭГ/ЭКГ? В цивилизованных странах будет еще какая-то платформа для командной работы. Назови какое-то нормальное опенсорс решение (без шуток было бы интересно)
	Ответить | Правка | Наверх | Cообщить модератору

	344. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 15-Янв-24, 16:35
	Путаешь интерфейс и подложку. На подложке в этих же аппаратах - далеко не винда.
	Ответить | Правка | Наверх | Cообщить модератору

	350. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 17:18
	Возможно, но например банкоматы я встречал на винде. Винда IoT Core вполне достаточно большому кол-ву медицинской техники. Я уже молчу про Windows CE) Хотя объективно для серьезного аппарата (типа радиотерапия или КТ) я бы постремался использовать ядро линукс. Уж лучше пусть будет какой-нибудь РТОС.
	Ответить | Правка | Наверх | Cообщить модератору

	365. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 15-Янв-24, 18:27
	Банкомат - слишком примитивное устройство. Дисплей, кейпад, принтер и полтора ком-порта для кард-ридера и денег.
	Ответить | Правка | Наверх | Cообщить модератору

	366. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 15-Янв-24, 18:28
	В самом аппарате, который деньги выдаёт, контроллеры бывают разные, но они автономные. Где-то возможно и линуха даже.
	Ответить | Правка | Наверх | Cообщить модератору

	654. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 19-Янв-24, 20:07
	> Банкомат - слишком примитивное устройство. Дисплей, кейпад, принтер и полтора ком-порта > для кард-ридера и денег. У одной фирмы я видал там характерную лужайку с кнопкой Start. Или, не менее пафосный скринсейвер с логотипом XP. А у другой после проскока питалова - вся загрузка как на ладони, но там еще после старта антивирь пашет. И пока он пашет - тадам - можно шарахаться по морде банкомата жамкая сенсорный экран, проводник точно запускается. Потом конечно морда запускается и все вышибает, но пошариться проводником по банкомату... ээ... ну им так кто-нибудь и бабки снимет при случае наверное. В мои планы такой тупой кибекриминал не входил, чисто проверка "так можно было?!", но оказалось что таки - можно! :)))
	Ответить | Правка | К родителю #365 | Наверх | Cообщить модератору

	353. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (353), 15-Янв-24, 17:37
	Не хочется тебя расстраивать, но бизнесу нужно чтобы всё просто работало за минимальную стоимость, ничего личного. Будет это линукс, винда, или ещё что-то - бизнесу неважно. А построением мирового open-source коммунизма пусть занимается кто-то другой.
	Ответить | Правка | К родителю #312 | Наверх | Cообщить модератору

	342. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Tron is Whistling (?), 15-Янв-24, 16:32
	Всё очень просто. На интерфейсе для врача - винда. В МРТ, на рентгене, в аппарате УЗИ. А вот внутри аппарата - либо линуха, либо RTOS'ы.
	Ответить | Правка | К родителю #288 | Наверх | Cообщить модератору

	427. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от beck (??), 15-Янв-24, 22:55
	Внутри аппаратов чистое железо с прошивкаме. Накой там ОС?
	Ответить | Правка | Наверх | Cообщить модератору

	430. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 15-Янв-24, 23:04
	Прошивки прямо в металле? :D Вы недооцениваете современные прошивки.
	Ответить | Правка | Наверх | Cообщить модератору

	343. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 15-Янв-24, 16:33
	То есть винда тебе только картинку рисует, всеми же серьёзными задачами занимаются совершенно другие ОС.
	Ответить | Правка | К родителю #288 | Наверх | Cообщить модератору

	435. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (482), 15-Янв-24, 23:22
	Совершенно другие ОС даже не в состоянии нарисовать картинку, ОК.
	Ответить | Правка | Наверх | Cообщить модератору

	501. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 16-Янв-24, 11:25
	Там программеры другие, они занимаются не рисованием картинок, а работой со сложным железом.
	Ответить | Правка | Наверх | Cообщить модератору

	507. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Советский инженер (ok), 16-Янв-24, 12:15
	ви таки недооцениваете сложность рисования картинок по данным, полученным от сожного железа.
	Ответить | Правка | Наверх | Cообщить модератору

	516. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 16-Янв-24, 13:48
	Картинки рисовать - тоже сложно, не спорю, но это больше математика. Ну и плюс весь видеовывод и т.п. как раз винде и отдаётся.
	Ответить | Правка | Наверх | Cообщить модератору

	518. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 16-Янв-24, 13:49
	Короче есть разница: тупо на CPU процессить данные или работать с кучей датчиков и актуаторов.
	Ответить | Правка | К родителю #507 | Наверх | Cообщить модератору

	392. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (293), 15-Янв-24, 19:17
	>Я прихожу к врачам, в мрт винда, на рентгене винда, в аппарате узи винда. Потому, что в Скрепной медоборудование закуплено 15-летней назад разработки? А то и ваще б/у.
	Ответить | Правка | К родителю #288 | Наверх | Cообщить модератору

	484. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (482), 16-Янв-24, 06:47
	Закупаем такие современное оборудование (с условием, что нам его кто-то продаст)… а там опять винда. Да что ж такое.
	Ответить | Правка | Наверх | Cообщить модератору

	354. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (115), 15-Янв-24, 17:39
	Ядро винды написано на Си
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

	529. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от хрю (?), 16-Янв-24, 14:53
	>Ядро windows написано на С++. Откуда вы эту муйню все копируете? Ядро винды написано и продолжает писаться на C. Так же там есть asm и якобы его там достаточно много. Никакого С++ и чего-то ещё там нет и скорее всего не будет. Винду далеко не идиоты пишут.
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

	596. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (589), 16-Янв-24, 23:57
	Достаточно интервью в котором мелкомагкие переписывальщики на раст говорят о том, что занимаются переводом внутренних C++ типов в эквивалентные раст.
	Ответить | Правка | Наверх | Cообщить модератору

242. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
Сообщение от Вирт (?), 15-Янв-24, 11:26
> и язык C++ стал лучше Вроде же не 1 апреля еще? Автор цитаты выше Перепил на новый год и думает что наступило 1 апреля? Основное возражение для С++ в ядре было, что он слишком много прячет от разработчика, а для ядра это неприемлимо. И с тех пор C++ стал хуже, появилось еще 100500 способов выстрелить себе в ногу. Как, как язык поддерживающий обратную совместимость может стать лучше? Или пометили как устаревшие std::auto_ptr и std::vector<bool> и все, все проблемы решены?
Ответить | Правка | Наверх | Cообщить модератору

	286. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (278), 15-Янв-24, 13:41
	> И с тех пор C++ стал хуже, появилось еще 100500 способов выстрелить себе в ногу. Все способы выстрелить себе в ногу в C++ - это исключительно наследие C. На чистом плюсовом коде (без сырых указателей, сишных строк и функций) выстрелить себе в ногу очень сложно. Правда сишники начинают беситься от ошибок компилятора, и начинают в обход компилятора фигачить свой сишный код, это да.
	Ответить | Правка | Наверх | Cообщить модератору

	314. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 15:00
	> начинают беситься от ошибок компилятора А кто не начнёт, когда в шаблонном коде  получаешь ошибку в коде кишок?
	Ответить | Правка | Наверх | Cообщить модератору

	454. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 16-Янв-24, 00:09
	> Все способы выстрелить себе в ногу в C++ - это исключительно наследие > C. На чистом плюсовом коде (без сырых указателей, сишных строк и > функций) выстрелить себе в ногу очень сложно. А дебильные классические типы целых чисел там как? Их так то и в си неплохо бы выпилить к хренам и сделать по уму, на основе C99 - и с "well defined behavior". Это спасло бы от дохреналиона багов и вулнов на ровном месте. И да - вообще забанить к хренам "int" (signed) как индексы. С расстрелом из реактивного г@вномета за это. Чтобы господам даже чисто теоритически в голову не приходило что в массив можно отрицательный индекс, бдаж!
	Ответить | Правка | К родителю #286 | Наверх | Cообщить модератору

	502. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 16-Янв-24, 11:26
	Ты не поверишь, но отрицательный индекс в массиве по указателю - очень даже востребован.
	Ответить | Правка | Наверх | Cообщить модератору

	512. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Fyjy (?), 16-Янв-24, 13:41
	В производстве овно кода и CVEшек? Верю! Можно просто открывать новости пенька и каждый 2 недели читать про очередную уязвимость от любителей поиграться с индексами. Но вот для надежных систем это только во вред.
	Ответить | Правка | Наверх | Cообщить модератору

	519. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 16-Янв-24, 13:51
	Вот есть у меня вот прямо индекс указателей на элементы. Есть поинтер на какой-то указатель в этом индексе. Мне надо предыдущий взять. Далее чего?
	Ответить | Правка | Наверх | Cообщить модератору

	527. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 16-Янв-24, 14:45
	Так твой пример сам по себе небезопрасный. И на этот случай есть унарный --, знак тут всё ещё не нужен
	Ответить | Правка | Наверх | Cообщить модератору

	577. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 16-Янв-24, 20:00
	Мне не нужно менять сам указатель :)
	Ответить | Правка | Наверх | Cообщить модератору

	656. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (-), 19-Янв-24, 20:15
	> Вот есть у меня вот прямо индекс указателей на элементы. Есть поинтер > на какой-то указатель в этом индексе. > Мне надо предыдущий взять. Далее чего? Уволить того кто код так пишет к хренам - зачем вам этот генератор CVE в тиме?
	Ответить | Правка | К родителю #519 | Наверх | Cообщить модератору

	658. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 19-Янв-24, 21:41
	Да не, я не против, чтобы ты вместо одного сервера у меня 10 купил, но ты ведь не купишь.
	Ответить | Правка | Наверх | Cообщить модератору

	665. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 20-Янв-24, 12:44
	> Да не, я не против, чтобы ты вместо одного сервера у меня > 10 купил, но ты ведь не купишь. Я как махровый сишник готов поспорить что все то же самое можно было сделать значительно менее ректально. Без явно невалидных на глаз (и статический анализатор) действий. То что вы делаете что-то ректально и гордитесь этим намекает что хрустики все же имеют свой понйт в своем желании вас уйти. Той е#$%нины в коде лично я не желаю видеть в принципе.
	Ответить | Правка | Наверх | Cообщить модератору

	666. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Tron is Whistling (?), 20-Янв-24, 13:04
	На самом деле пусть уходят - чище будет.
	Ответить | Правка | Наверх | Cообщить модератору

	678. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 21-Янв-24, 21:09
	> На самом деле пусть уходят - чище будет. Инихрена себе уровень самокритики. Вот это вы круты. Я правильно понимаю что вы считаете что без вас в проекте станет лучше? O_O Да, это довольно необычно для опеннет...
	Ответить | Правка | Наверх | Cообщить модератору

	655. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (655), 19-Янв-24, 20:12
	> Ты не поверишь, но отрицательный индекс в массиве по указателю - очень > даже востребован. А вот эксперты по фигурному прострелу пяток с заподвыподвертом пожаловали. Я все понимаю - но вот в именно таком стиле CVE получаются. Воон там зубр сабмитил отрицательный индекс массиву если вооон те параметры на вход дать. Не, так не задумано - просто он аргументы функции на вход не чекал, и получив воооон те параметры, лихо проматывал индекс не только до 0 но и за него. Ну, подумаешь, по чужой памяти пошарился, а то и в провод слил, "ишь ты, карманный вариант heartbleed'а". Гнать таких програмеров ссаными тряпками и ср@ной метлой.
	Ответить | Правка | К родителю #502 | Наверх | Cообщить модератору

	514. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Fyjy (?), 16-Янв-24, 13:44
	> сделать по уму, на основе C99 - и с "well defined behavior". Хахахаха, ты предлагаешь невозможное. Сейчас набигут фанатики и объяснят тебе, что UB это лучшее что есть в дыряшке, приведут кучу примеров где оно ну обязательно и без них даже кушать нельзя. Самое глупое оправдание которое мне тут попадалось было "если напишут без уязвимостей, как мы будем рутовать телефоны"
	Ответить | Правка | К родителю #454 | Наверх | Cообщить модератору

247. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от nc (ok), 15-Янв-24, 11:47
Лучше уж Rust. C++ это нагромождение костылей, если все это (особенно метапрограммирование на шаблонах) попадет в ядро то туши свет. Rust хоть и имеет более непривычный синтаксис чем С++, но все же разработан с учетом опыта многих других языков.
Ответить | Правка | Наверх | Cообщить модератору

	254. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (253), 15-Янв-24, 12:39
	Да, только раст спасёт ведро линукс!
	Ответить | Правка | Наверх | Cообщить модератору

	262. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от nc (ok), 15-Янв-24, 12:53
	Да дело не в том что кто-то чего-то спасет. Языки программирования объективно развиваются. Когда создавали Си, многих возможностей просто не было. Си получился очень удачным, но все-же есть у него и недостатки, и чем сложнее проект тем чаще они вылезают. А вот тащить С++ я бы не стал. Именно потому, что он развивался эволюционно. Добавляли фичи, потом оказывалось что добавили не совсем удачно - добавляли поверх новые, а старые не совсем удачные оставляли... в результате получилось некое нагромождение всякого разного. Постоянное беспокойство за "обратную совместимость" до добра не доводит никогда. А все что нужно было сделать - что-то вроде pragma version в начале каждого сpp файла. И для новых версий можно было бы не бояться ломающих изменений в языке. Компиляторы бы поддерживали сразу несколько версий, в результате программисты бы спокойно переходили на новые версии и по мере возможностей подтягивали бы старый код.
	Ответить | Правка | Наверх | Cообщить модератору

	294. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Серб (ok), 15-Янв-24, 13:57
	> А все что нужно было сделать - что-то вроде pragma version в начале каждого сpp файла. А опция --std компилятору не подойдет? :)
	Ответить | Правка | Наверх | Cообщить модератору

	331. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от nc (ok), 15-Янв-24, 15:40
	Для реализации ломающих изменений и сохранения возможности компиляции старых файлов - не подойдет. Кроме того, хранение версии языка отдельно от исходника само по себе плохо.
	Ответить | Правка | Наверх | Cообщить модератору

	337. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (115), 15-Янв-24, 15:56
	Это само по себе хорошо т.к. не нужно править дохринилиард прагм во всём репозитории при переходах на новые стандарты. Дерьмовее предложения, чем помечать каждый исходник версией, просто невозможно придуамать.
	Ответить | Правка | Наверх | Cообщить модератору

	561. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _oleg_ (ok), 16-Янв-24, 16:56
	> Это само по себе хорошо т.к. не нужно править дохринилиард прагм во > всём репозитории при переходах на новые стандарты. Дерьмовее предложения, чем помечать > каждый исходник версией, просто невозможно придуамать. Да нет. Наоборот. Если захочется применить в исходнике новые возможности, то ты туда _уже_ пойдёшь редактором. И поменять при этом pragma - не проблема. Исходник должен сообщать сам о себе версию стандарта. Это правильно и логично.
	Ответить | Правка | Наверх | Cообщить модератору

	563. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Серб (ok), 16-Янв-24, 17:14
	>> Это само по себе хорошо т.к. не нужно править дохринилиард прагм во >> всём репозитории при переходах на новые стандарты. Дерьмовее предложения, чем помечать >> каждый исходник версией, просто невозможно придуамать. > Да нет. Наоборот. Если захочется применить в исходнике новые возможности, то ты > туда _уже_ пойдёшь редактором. И поменять при этом pragma - не > проблема. Исходник должен сообщать сам о себе версию стандарта. Это правильно > и логично. Правильно и логично - когда не надо менять код под каждый новый стандарт. Любая необходимость менять должна быть исключением из правил. Вот эти исключения из правил и надо выявлять. Компилятор это делает. Можно было бы создавать отдельную утилиту, но зачем?
	Ответить | Правка | Наверх | Cообщить модератору

	568. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _oleg_ (ok), 16-Янв-24, 18:06
	> Правильно и логично - когда не надо менять код под каждый новый > стандарт. А зачем его менять, если как предлагается выше, компиляторы поддерживают разные версии? Есть у тебя исходик с pragma version 2014 и на здоровье.
	Ответить | Правка | Наверх | Cообщить модератору

	571. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Серб (ok), 16-Янв-24, 18:18
	>> Правильно и логично - когда не надо менять код под каждый новый >> стандарт. > А зачем его менять, если как предлагается выше, компиляторы поддерживают разные версии? > Есть у тебя исходик с pragma version 2014 и на здоровье. Например, что бы оптимизации сработали. Смотри lto.
	Ответить | Правка | Наверх | Cообщить модератору

	572. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _oleg_ (ok), 16-Янв-24, 18:51
	>>> Правильно и логично - когда не надо менять код под каждый новый >>> стандарт. >> А зачем его менять, если как предлагается выше, компиляторы поддерживают разные версии? >> Есть у тебя исходик с pragma version 2014 и на здоровье. > Например, что бы оптимизации сработали. Смотри lto. Если pragma version относится только к синтаксической части, то оптимизации здесь ни при чём и их можно рулить параметрами командной строки компилятора.
	Ответить | Правка | Наверх | Cообщить модератору

	617. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Серб (ok), 17-Янв-24, 12:46
	>>>> Правильно и логично - когда не надо менять код под каждый новый >>>> стандарт. >>> А зачем его менять, если как предлагается выше, компиляторы поддерживают разные версии? >>> Есть у тебя исходик с pragma version 2014 и на здоровье. >> Например, что бы оптимизации сработали. Смотри lto. > Если pragma version относится только к синтаксической части, то оптимизации здесь ни > при чём и их можно рулить параметрами командной строки компилятора. Стандарты очень часто вводят для включения возможности оптимизации. На старых стандартах возможностей оптимизации меньше. Или в вашем любимом языке это не так?
	Ответить | Правка | Наверх | Cообщить модератору

	618. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _oleg_ (ok), 17-Янв-24, 13:20
	> Стандарты очень часто вводят для включения возможности оптимизации. На старых стандартах > возможностей оптимизации меньше. Или в вашем любимом языке это не так? Оптимизации - расплывчатое понятие. Что я вижу в новых стандартах C и C++ это не какие-то скрытые оптимизации поверх старого синтаксиса, а как раз изменения в синтаксисе, добавление чего-то нового с целью упрощения чего-то старого. И для того, что бы повившиеся анонимные структуры, инициализация по именам полей структуры и т.п. работало, надо сделать таки изменения в исходном коде. Для этого туда надо зайти. И заодно поменять pragma version. Не вижу проблем.
	Ответить | Правка | Наверх | Cообщить модератору

	619. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Серб (ok), 17-Янв-24, 13:43
	На изменение обработки volatile смотрел?
	Ответить | Правка | К родителю #618 | Наверх | Cообщить модератору

	620. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Серб (ok), 17-Янв-24, 13:48
	На расширение того, что при constexpr уйдет в компиле тайм смотрел?
	Ответить | Правка | К родителю #618 | Наверх | Cообщить модератору

	346. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Серб (ok), 15-Янв-24, 16:49
	> Для реализации ломающих изменений и сохранения возможности компиляции старых файлов - не > подойдет. Странно, но именно для этого его и используют. Конечно там включается до.. гхм... очень много дефайнов, которые можно учесть в исходниках. > Кроме того, хранение версии языка отдельно от исходника само по себе плохо. Чем? Вносимые в язык изменения продуманы так, что если что-то работает - то будет работать. Если что-то не работает - то оно не соберётся и ты вынужден будешь внести изменения.
	Ответить | Правка | К родителю #331 | Наверх | Cообщить модератору

	338. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (115), 15-Янв-24, 15:58
	> Компиляторы бы поддерживали сразу несколько версий, в результате программисты бы спокойно переходили на новые версии и по мере возможностей подтягивали бы старый код. В результате программисты просто бы никуда не переходили. Совместимость со старыми стандартами и так достаточно глубокая по вермени. Проблемы обычно возникают с некорректным использованием поюсов.
	Ответить | Правка | К родителю #262 | Наверх | Cообщить модератору

	335. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
	Сообщение от Аноним (115), 15-Янв-24, 15:52
	rust разработан с учётом надёргивания из маргинальных ЯП фич, которые очень хотелось подёргать хипстерам из команды разработчиков. Другими словами, разработан с учётом опыта языков с низким практическим применением.
	Ответить | Правка | К родителю #247 | Наверх | Cообщить модератору

	559. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _oleg_ (ok), 16-Янв-24, 16:48
	> Лучше уж Rust. C++ это нагромождение костылей, если все это (особенно метапрограммирование > на шаблонах) попадет в ядро то туши свет. Rust хоть и > имеет более непривычный синтаксис чем С++, но все же разработан с > учетом опыта многих других языков. Про C++ согласен. Но и rust не нужен. Пусть пишут свои проекты. Зачем в ядро лезть. Там всё норм.
	Ответить | Правка | К родителю #247 | Наверх | Cообщить модератору

272. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
Сообщение от Аноним (263), 15-Янв-24, 13:01
>метапрограммирование >произвольные вычисления во время компиляции >безопасная работа с памятью Чего только не сделают, лишь бы переизобрести лисп в своем языке... Отправляйте всех любителей оного в нашу палату, пусть лучше на человеческом языке Mezzano OS пилят, а не гробят Линукс своими прогрессивными франкенштейнами.
Ответить | Правка | Наверх | Cообщить модератору

301. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
Сообщение от Аноним12345 (?), 15-Янв-24, 14:28
хруст до добра не доведет
Ответить | Правка | Наверх | Cообщить модератору

355. Скрыто модератором	+/–
Сообщение от Миллион глаз (?), 15-Янв-24, 17:53
https://habr.com/ru/articles/786366/ Забавное в комментах, все что нужно знать
Ответить | Правка | Наверх | Cообщить модератору

359. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–2 +/–
Сообщение от DEF (?), 15-Янв-24, 18:05
Какой смысл C заменять на C++? Между ними нет никакой принципиальной разницы. C++ такой же морально устаревший динозавр, как и C, просто еще более уродливый и окостыленный. Вот Rust, Carbon или Zig - более лучшие и современные кандидатуры. Я лично голосую за Rust, ибо он предлагает принципиально новую парадигму программирования, как бы там не пыхтели хейтеры этого языка.
Ответить | Правка | Наверх | Cообщить модератору

	369. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (194), 15-Янв-24, 18:35
	Никаких новых парадигм в расте нету.Тогда уже лисп давайте
	Ответить | Правка | Наверх | Cообщить модератору

	428. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 15-Янв-24, 22:55
	> Никаких новых парадигм в расте нету.Тогда уже лисп давайте Путались в указателях, теперь будут путаться в скобочках.
	Ответить | Правка | Наверх | Cообщить модератору

	386. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (386), 15-Янв-24, 19:04
	1. Раст требует грёбанного тулчейна. 2. Хотя-бы потому, что на крестах доступны растопримитивы и это позволит инкрементно переводить код на раст. То есть сначала потихоньку сишный код переписывается на кресстовый. Потом крестовый приводится к растоподобному стилю. Потом переписывается на раст, фиксятся баги компиляции, фиксы бэкпортируются на кресты. Каждый патч проходит ревью. Тем самым обеспечивается преемственность, последовательность и контроль на каждом этапе.
	Ответить | Правка | К родителю #359 | Наверх | Cообщить модератору

	496. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от Аноним (499), 16-Янв-24, 10:38
	Именно, а Раст без тулчейна и с unsafe теряет свои главные преимущества и принципиально ничем не отличается от Си.
	Ответить | Правка | Наверх | Cообщить модератору

	508. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Советский инженер (ok), 16-Янв-24, 12:20
	> Раст требует грёбанного тулчейна. а с или с++ не требуют грёбанного тулчейна !? как же тогда текстовые файлы с исходным кодом преобразуються в выполняемые бинари/библиотеки?
	Ответить | Правка | К родителю #386 | Наверх | Cообщить модератору

	558. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _oleg_ (ok), 16-Янв-24, 16:47
	> Какой смысл C заменять на C++? Между ними нет никакой принципиальной разницы. > C++ такой же морально устаревший динозавр, как и C, просто еще > более уродливый и окостыленный. Вот Rust, Carbon или Zig - более > лучшие и современные кандидатуры. Я лично голосую за Rust, ибо он > предлагает принципиально новую парадигму программирования, как бы там не пыхтели хейтеры > этого языка. Сам ты морально устаревший. C такой же устаревший как ложка с вилкой. Да что это за болезнь такая тащить всё модное всюду без разбора? А оно, вообще, в ядре надо? Надо ядру принципиально новая парадигма? Что за гуманитарный бред? C работает, справляется со своей задачей хорошо. Проще ЯП при его возможностях нет на данный момент. Сложнее и хуже - навалом. Нафига это всё тащить в ядро - непонятно. От скуки и скудоумия. Работой займись.
	Ответить | Правка | К родителю #359 | Наверх | Cообщить модератору

	627. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (631), 17-Янв-24, 17:25
	>Да что это за болезнь такая тащить всё модное всюду без разбора? Обычная болезнь зумеров. Знаний - мало, энергии - много, страсть ко всему новому (для их мозга). Увидели - слюни потекли, побежали ставить/канпелять. Плюс, такие же клоуны как они подливают масла в огонь своими "хелловорлдными" статейками (которыми только подтереться). И вот уже кто-то всерьёз обсуждает Раст.... *фэйспалм*
	Ответить | Правка | Наверх | Cообщить модератору

381. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
Сообщение от Товарищ (?), 15-Янв-24, 18:57
Нет, к чёртовой матери таких товарищей.
Ответить | Правка | Наверх | Cообщить модератору

480. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от Вы забыли заполнить поле Name (?), 16-Янв-24, 03:18
Не узнаю вас, анонимы. Ловко вас провели. Что, уже идея с растом не так плоха как раньше?
Ответить | Правка | Наверх | Cообщить модератору

	495. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (499), 16-Янв-24, 10:36
	Судя по реакции, скорее наоборот. Под угрозой включения Rust в ядро все уже согласны и на C++. Тем более что его последние стандарты сильно продвинулись по вопросу безопасности памяти.
	Ответить | Правка | Наверх | Cообщить модератору

532. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от хрю (?), 16-Янв-24, 14:57
Откуда вообще взялось это ограничение на язык для ядерных модулей? Сишные интерфейсы и структуры они же в любой язык встраиваются на in/out на раз-два. Почему нельзя скомпилять ядерный модуль на с++, zig, rust да на любом язяке. Не понимаю.
Ответить | Правка | Наверх | Cообщить модератору

	544. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 16-Янв-24, 15:43
	> Откуда вообще взялось это ограничение на язык для ядерных модулей? Сишные интерфейсы и структуры они же в любой язык встраиваются на in/out на раз-два. Почему нельзя скомпилять ядерный модуль на с++, zig, rust да на любом язяке. Не понимаю. * Нужна поддержка сбоки модулей на другом языке. * Нужно выработать единый интрефейс для модулей на языке. Сейчас ядро про эти языки ничего не знает. Вот если сделать чтобы модули можно было писать независимо на любом языке. Насколько я понимаю для WASI (https://wasi.dev/) - это одна из целей.
	Ответить | Правка | Наверх | Cообщить модератору

	607. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 17-Янв-24, 07:07
	>Вот если сделать чтобы модули можно было писать независимо на любом языке Вот поэтому высокоуровневых программистов и веб-мака* нельзя подпускать к системному программированию. У них мышление не нормальное.
	Ответить | Правка | Наверх | Cообщить модератору

	634. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Янв-24, 02:53
	>>Вот если сделать чтобы модули можно было писать независимо на любом языке > Вот поэтому высокоуровневых программистов и веб-мака* нельзя подпускать к системному программированию. > У них мышление не нормальное. Что плохого в идее WASI?
	Ответить | Правка | Наверх | Cообщить модератору

535. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
Сообщение от Аноним (-), 16-Янв-24, 15:25
Я зол. В низкоуровневых разработках нет места объектно-ориентированным языкам. Си плюс-плюс запретить. Всё! Такие вопросы вообще не должны обсуждаться.
Ответить | Правка | Наверх | Cообщить модератору

	552. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от Аноним (499), 16-Янв-24, 16:20
	Но поскольку разработчикам ядра Linux виднее, что им делать, обсуждение перехода ядра на C++ продолжается, а ты можешь и дальше писать свои бессильные гневные комментарии.
	Ответить | Правка | Наверх | Cообщить модератору

	556. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+1 +/–
	Сообщение от _oleg_ (ok), 16-Янв-24, 16:43
	> Я зол. В низкоуровневых разработках нет места объектно-ориентированным языкам. Си плюс-плюс > запретить. Всё! Такие вопросы вообще не должны обсуждаться. Да ладно бы ОО. C++ даже как ОО не очень. Просто страшное недоразумение какое-то. Сложный, запутанный и кривой.
	Ответить | Правка | К родителю #535 | Наверх | Cообщить модератору

	588. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 16-Янв-24, 23:11
	Не тролинга ради вопрос: в каком языке ООП сделано как надо?
	Ответить | Правка | Наверх | Cообщить модератору

	592. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от DEF (?), 16-Янв-24, 23:26
	Нормальное ООП должно быть основано на интерфейсах. Никакого наследования. Тем более множественного. Более-менее нормальное ООП в Java.
	Ответить | Правка | Наверх | Cообщить модератору

	608. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (608), 17-Янв-24, 07:34
	>Никакого наследования. Да ты чё, сам придумал? Но тогда почитай, на каких столпах основано это самое ООП.
	Ответить | Правка | Наверх | Cообщить модератору

	612. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _oleg_ (ok), 17-Янв-24, 11:18
	> Не тролинга ради вопрос: в каком языке ООП сделано как надо? smalltalk, от автора термина ООП. Erlang. Что ещё хз. Это из того, что видел. C++ и Java точно не из этого. Но в java хотя бы насколько смогли улучшили ситуацию по сравнению с C++, выкинув некоторые извращения и ненужные усложнения.
	Ответить | Правка | К родителю #588 | Наверх | Cообщить модератору

	639. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Серб (ok), 19-Янв-24, 14:37
	>> Не тролинга ради вопрос: в каком языке ООП сделано как надо? > smalltalk, от автора термина ООП. Erlang. Что ещё хз. Это из того, > что видел. C++ и Java точно не из этого. Но в > java хотя бы насколько смогли улучшили ситуацию по сравнению с C++, > выкинув некоторые извращения и ненужные усложнения. Набор микросервисов с динамической типизацией. В качестве примера ООП это лучше не приводить. Он был первым, который вступил на тропу. Но свернул совсем не туда.
	Ответить | Правка | Наверх | Cообщить модератору

	682. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от fuggy (ok), 22-Янв-24, 23:49
	В Java поправили diamond problem, зато напихали default interface. Отличие абстрактного класса от default interface теперь не многие назовут. А вы эти static utils *anything видели. Анемичные модели. Это разве похоже на ООП? Типичный процедурный стиль уровня C, с той разницей что все функции должны в классах лежать.
	Ответить | Правка | К родителю #612 | Наверх | Cообщить модератору

	683. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _oleg_ (ok), 23-Янв-24, 11:36
	> В Java поправили diamond problem, зато напихали default interface. Отличие абстрактного > класса от default interface теперь не многие назовут. > А вы эти static utils *anything видели. Анемичные модели. Это разве похоже > на ООП? Типичный процедурный стиль уровня C, с той разницей что > все функции должны в классах лежать. Кто ж сказал, что java идеальна? C# в этом плане получше, по свидетельствам очевидцев.
	Ответить | Правка | Наверх | Cообщить модератору

	626. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (631), 17-Янв-24, 17:21
	Например, в D (чистый преемник С++). Нет множ.наследования (порождающие больше проблем, чем решающие). Есть traits. Шаблоны. Да вообще ВСЁ, что может понадобиться адекватному ООПщику - чего не пишется, спрашивается??
	Ответить | Правка | К родителю #588 | Наверх | Cообщить модератору

	640. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Серб (ok), 19-Янв-24, 14:40
	> Нет множ.наследования (порождающие больше проблем, чем решающие). Тут только одна проблема - это самое порождение проблем родит их для разработчика языка. Пользователя этого языка эти проблемы не должны касаться. Для пользователя это звучит как: "Ну не смогла я, не смогла".
	Ответить | Правка | Наверх | Cообщить модератору

555. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от _oleg_ (ok), 16-Янв-24, 16:41
Что ж людям-то не работается спокойно. То rust с его кошмарным синтаксисом, то C++ - кромешное нагромождение всего и вся - пытаются запихнуть в ядро. Ёплки-палки, да работайте просто уже. Хернёй не страдайте.
Ответить | Правка | Наверх | Cообщить модератору

	560. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (-), 16-Янв-24, 16:53
	>C++ - кромешное нагромождение всего и вся Я слушал интервью Страуструпа. Он сам хотел этого - язык в котором есть всё в виде объектов.
	Ответить | Правка | Наверх | Cообщить модератору

	562. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	–1 +/–
	Сообщение от _oleg_ (ok), 16-Янв-24, 17:04
	>>C++ - кромешное нагромождение всего и вся > Я слушал интервью Страуструпа. Он сам хотел этого - язык в котором > есть всё в виде объектов. Дело не в том, что там всё в виде объектов. Дело в том, что там просто кошмарный ужас из всего. Если хочется ООП, то надо смотреть на другие ЯП. C++ это не ООП. Это наркоманский приход. И да, есть интервью Страуструпа, где он признаётся, что хотел ЯП замороченный настолько, что бы у работодателя не вызывало вопросов требование больших ЗП тем, кто несмотря ни на что в этом кошмаре разберётся. Он добился своего :-). Но мы этим пользоваться не обязаны.
	Ответить | Правка | Наверх | Cообщить модератору

	597. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 17-Янв-24, 02:33
	> И да, есть интервью Страуструпа, где он признаётся, что хотел ЯП замороченный настолько, что бы у работодателя не вызывало вопросов требование больших ЗП тем, кто несмотря ни на что в этом кошмаре разберётся. Можно ссылку?
	Ответить | Правка | Наверх | Cообщить модератору

	598. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Полная отсебятина (?), 17-Янв-24, 02:57
	В книге The C++ Programming Language, 4th Edition, подчеркиваеться что Страуструп, никогда не говорил что язык C++ это ООП язык, цитирую I wince when someone characterizes C++ exclusively through one of these styles (e.g., ‘‘C++ is an object-oriented language’’) or uses a term (e.g., ‘‘hybrid’’ or ‘‘mixed paradigm’’) to imply that a more restrictive language would be preferable. The former misses the fact that all the styles men- tioned have contributed something significant to the synthesis; the latter denies the validity of the synthesis. The styles mentioned are not distinct alternatives: each contributes techniques to a more expressive and effective style of programming, and C++ provides direct language support for their use in combination. дальше можно не читать этот жирный троллинг.
	Ответить | Правка | Наверх | Cообщить модератору

	613. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от _oleg_ (ok), 17-Янв-24, 11:22
	>> И да, есть интервью Страуструпа, где он признаётся, что хотел ЯП замороченный настолько, что бы у работодателя не вызывало вопросов требование больших ЗП тем, кто несмотря ни на что в этом кошмаре разберётся. > Можно ссылку? Не могу найти оригинал. Перепечатка тут: http://harmful.cat-v.org/software/c++/I_did_it_for_you_all . Хз насколько это троллинг, но, зная C++ в сравнении с другими ЯП, охотно воспринимается за чистую монету.
	Ответить | Правка | К родителю #597 | Наверх | Cообщить модератору

605. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от Аноним (20), 17-Янв-24, 04:39
Майкрософт вот не тупит и на расте уже Винду переписывает: https://www.theregister.com/2023/04/27/microsoft_windows_rust/ А комментаторы опеннета всё живут умом где-то в в 90-ых.
Ответить | Правка | Наверх | Cообщить модератору

	606. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+3 +/–
	Сообщение от Аноним (-), 17-Янв-24, 07:04
	Приводить Майкрософт (компанию, которую все презирают), как пример для подражания. Ну, это даже не шутка, это жирнейший троллинг.
	Ответить | Правка | Наверх | Cообщить модератору

	625. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (631), 17-Янв-24, 17:16
	То, что в M$ работают индусские м@к@ки, порождает и соотв. решения - вот Раст к примеру :)) Абсолютно необоснованное решение. Как и попытки заигрывания в Линукс внутри венды. Сейчас M$ далеко не "гигант ИТ" - это монстр, который полностью сгнил внутри и идёт чисто как зомби - по инерции. Венда-10-11 - это очевидный тупик, забагованный больше алкашного дивана. .NET Core движется в ___еня. Студия не развивается толком, т.к. требуется ПОЛНОЕ переписывание. На плаву держатся серверные системы и MS SQL (видимо, обезьян не подпускают к золотой курице). Другими словами, найдите пример поинтереснее.
	Ответить | Правка | К родителю #605 | Наверх | Cообщить модератору

	657. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (-), 19-Янв-24, 20:20
	> внутри и идёт чисто как зомби - по инерции. Венда-10-11 - > это очевидный тупик, забагованный больше алкашного дивана. .NET Core движется в > ___еня. Студия не развивается толком, т.к. требуется ПОЛНОЕ переписывание. Да это вы просто не видели что они с виндофоном вытворяли. Еще и нокию за собой утопили, угробив все наработки UI/UX от нокии, с...ки!
	Ответить | Правка | Наверх | Cообщить модератору

621. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от Аноним (631), 17-Янв-24, 14:41
Заскорузлые мозги => устаревшие решения. Почему не D ?? Для кого развивали "преемника С++"? Там же всё по-уму сделано, а популяризация его в линукс-камьюнити только ещё больше поможет языку.
Ответить | Правка | Наверх | Cообщить модератору

	632. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+2 +/–
	Сообщение от Аноним (632), 18-Янв-24, 00:09
	Если бы его грамотно пиарили и больше людей в разработку включили, а так имеем что имеем. Но он еще вполне жив, так что посмотрим.
	Ответить | Правка | Наверх | Cообщить модератору

667. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от Аноним (667), 20-Янв-24, 13:34
Вкатывающимся ядроразрабам помимо знания сишки нужно будет отлично знать кресты с их шаблонной магией и прочими непотребствами стандарта на много тысяч страниц. Таким образом резко повышается порог вхождения.
Ответить | Правка | Наверх | Cообщить модератору

671. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
Сообщение от Аноним (671), 21-Янв-24, 03:53
С++ и С имеют множества недостатков от которых некоторые современные языки вылечены. Проблема в том что разработчики компиляторов и железа в первую очередь поддерживают С,С++ и в стандартизации — разных поставщиков и наборе инструментов. Поэтому выигрывает тот язык, который сумеет буквально его поглощать трансляцией в другой язык. Таких пока вроде нет и вряд ли будет — из-за множества ньюансов дешевле нанять команду разработчиков которые будут переводить из С на свой язык библиотеки и фреймворки. А вот локальные миссии по созданию цифровой экосистемы могли бы дать результат, если целенаправленно двигаться лет так 10–15. Но миссии это у американцев, потому что у них agile процессы.
Ответить | Правка | Наверх | Cообщить модератору

	693. "Дискуссия об использовании языка C++ для разработки ядра Lin..."	+/–
	Сообщение от Аноним (693), 28-Мрт-24, 14:10
	Поток сознания
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема