Продолжим тем, что глупо добавлять структуры только для того, чтобы уменьшить число полей в каждой из них. Это вам не Ява, где шаг вправо-шаг влево - и у вас сонаркуб заругается, что в структуре больше двух полей, давайте, разбивайте на несколько структур, даже если смысла в этом нет, просто первую половину полей в одну структуру, вторую половину - во вторую.

И закончим на соседней новости, где просто изменением порядка полей в большой структуре добились увеличения производительности на 40%. В случае со вложенными структурами эта оптимизация была бы где-то в диапазоне от "выглядит бредово" до "это невозможно".

Что значит мы? Это задачи такие. И не все делается в одиночку. Что требуется для работы с устройствами и протоколами.
А в итоге, иногда, строки в исходнике распухают за 400 символов. ;)
Отформатируешь, так будет каша, в которой не разобраться.
Впрочем, что где то плохо спроектировано я соглашусь. Матерюсь же. ;)

А подобную инициализацию в портянки переписывать? 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, и кто там еще

Так, идея в поддержке Си - исходников, а не переписывании.

1. Да, я это использую.
Но не так и редко бывает на ровном месте и
constexpr variable must be initialized by a constant expression
Особенно во встраиваемом ПО,что по духу ближе к ядру, чем пользовательские приложения.

2. После обкладывания constexpr всего и вся правда ведь исходник и красивей и читаемей?
Поэтому, использую не в всегда.

Благодарю. Жаль что с constexpr оно только с c++20 только, а то в embedded в ходу компиляторы и постарее. Но, уже лучше.

А я сделал себе верификацию ряда операций в компилтайме, скажем что я в 32 бит регистре не трогаю 35-й бит. Почти хруст получился. Даже не тормозит особо. В сабже кстати есть зачатки этого добра откуда я и содрал идею.

Хотя круче всего это в Zig сделано - там можно компил тайм предвычисления юзая стандартный синтаксис яп. Плюсы в этом смысле - убогие полумеры, ибо препроцессор с отдельным синтаксисом никуда не делся. А какой-нибудь constexpr знатный горбыль так то.

Говорят, что у Раста мнимая безопасность, потому что есть unsafe (который в случае ошибки при работе с памятью, укажет разработчику, куда стоит смотреть в первую очередь), но код на плюсах - весь unsafe

А вы часто вот именно gcc сами компилите, чтобы разницу в времени компила gcc ощутить? Так то его заметно тормознее себе перекомпиливать стало. Я это еще и практикую, так что знаю о чем говорю.

На скорость работы скомпиленой прогрыммы это может и не влиять. А вот на скорость компила очень даже. Ну и вот проги на плюсах - заметно дольше компилятся "при прочих равных" (e.g. примрено одинаковая функциональность).

В общем, после окончания споров "табы/пробелы" появляется множество других интересных и продуктивных споров на тему того, сколько именно пробелов использовать. Таким образом, находится и работа для тех, кому код писать не получается, а поучаствовать в разработке охота.

Не лучше. Таб = 1 байт, пробелы >1 байта.

Ложь. Едет, если в редакторе настроена замена пробелов табуляциями. То есть от настроек редактора зависит.

Вы только что рассказали почему powershell - ацтой каких мало. Ах да, автодополнение в том уродце не работает по сути никак, чтобы вы уж точно сломали пальцы. Как-то так и понимаешь где индусы, а где гении.

Ну, говоря за себя - если у них референсная реализация на LLVM я лучше тогда хруст поизучаю. Когда в gcc нормально запилят, не раньше. Зависеть на 100% от выходок гугли и эпла как-то не хочется. Тем более что эпл уже начал характерную бадягу с особенным, уличным LLVM в Xcode для себя и вторым сортом - для остальных.

Пару ножек?

вот умора, язык разработан для написания ядер и прочей системщины более 50 лет назад.
имеет нескольео стандартов ,но без гну/ms костылей ядра ОС так и не собираются.

и эти же "стандартизаторы" вещают про стандарты.

Не тормози, сникерсни! Если либа в .c/.cpp и ее отдельным .so сделали - все три проги поюзают один shared lib, если либу так собрать. Будет реюз кода либы.

А если это все было в header-only - опа, хидер .so не сделаешь! И все три получат свои приватные реализации фич которые они оттуда использовали и реюз кода не состоится. Это и есть обратная сторона header only. И интересно, чем тут дизассемблер поможет? Бывают конечно еще псевдолибы где кроме препроцессора и определений нихрена нет, но он видимо про полновесные хидеры с кодом.

Один файл компилируется в объектник с включенным заголовочником.

Другой файл генерируется объектник с включенным  заголовочником.

Оба содержат одинаковые сгенерированные функции.

Теперь линкуем это в один бинарь и получаем ожидаемый нежданчик.

А сколько на сегодня Раста в сетевой подсистеме ядра? Помоему, пока что хрен целых, хрен десятых.