The OpenNET Project / Index page

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

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


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

Оглавление

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

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


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

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

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




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

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