The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

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

Подробнее: https://www.opennet.ru/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 
Ответить | Правка | Наверх | Cообщить модератору

669. Скрыто модератором  +/
Сообщение от n00by (ok), 20-Янв-24, 15:36 
Ответить | Правка | Наверх | 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.ru/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 +/
Сообщение от Синий попугайemail (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..."  +/
Сообщение от freehckemail (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..."  +/
Сообщение от freehckemail (ok), 16-Янв-24, 15:27 
Боюсь, что это ты не понял. Данная статья просто предостерегает разработчиков о том, что стек имеет весьма ограниченный размер, и даёт указания, как с ним следует работать. Ни о какой защите речи не ведётся. Это самый обычный стек.
Ответить | Правка | Наверх | Cообщить модератору

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

553. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/
Сообщение от freehckemail (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 +/
Сообщение от 3dravenemail (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 +/
Сообщение от asaaddxasaaddemail (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..."  +/
Сообщение от bulbasaloemail (?), 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..."