The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Дискуссия об использовании языка C++ для разработки ядра Linux, opennews (??), 14-Янв-24, (0) [смотреть все]

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


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ообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру