The OpenNET Project / Index page

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



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

Оглавление

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

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


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

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

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




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

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