The OpenNET Project / Index page

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



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

Оглавление

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

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


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

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

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




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

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