The OpenNET Project / Index page

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



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

Оглавление

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

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


86. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +1 +/
Сообщение от Синий попугайemail (ok), 15-Янв-24, 00:18 
Разрешите поинтересоваться? Что именно подразумевает header only и почему это настолько плохо?
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

97. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/
Сообщение от Аноним (97), 15-Янв-24, 01:21 
>Что именно подразумевает header only

Либа со сложным и/или большим кодом (а если код простой и небольшой, который вообще каждый может написать влёгкую за пару строчек - то нафига либа?), которую позиционируют как удобную для включения в проект за счёт того, что она представляет собой один или несколько несколько h-файлов, содержащих реализацию алгоритма. Сюда для целей "вон из профессии" не включаются небольшие header-only либы, предназначение которых есть compile-time вычисления. Пример такого хлама - nlohmann/json и CLI11. Такие либы действительно в некотором смысле удобно включать проект, путём простого копирования их в папку с хедерами и подключения хедера, или путём использования git-подмодуля.

>почему это настолько плохо?

a.cpp <- lib1.hpp
b.cpp <- lib1.hpp
c.cpp <- lib1.hpp

В результате у нас тормоза при компиляции, и в каждый бинарь включена своя копия реализации. Это если a.cpp, b.cpp, c.cpp дают отдельные бинарники. Если всё линкуется в один бинарник, то вообще может быть ошибка линковки в случае криворукости разраба header-only либы. Если же он додумался сделать всё с inline, то ошибки линковки не будет, но копирование реализации и тормоза никуда не денутся. Любое изменение реализации либы приведёт к полной перекомпиляции проекта, а в случае отдельного хэдера с интерфейсом и линковке как OBJECT изменение реализации приведёт только к перекомпиляции файла с реализацией и перелинковке. Разумеется, при header-only либе ни о каком динамическом связывании, когда перелинкуется только бинарник либы, и версия либы вообще выбирается пользователем и не требует перекомпиляции зависящей от либы программы (необходимо для эффективной работы пакетного менеджера) даже и речи не идёт.

Программист свою программу должен писать так. чтобы пользователям этой пртграммы было удобно. Так как в опенсорсе программист зачастую сам пользователь, то тут это должно проявляться особенно. Но многие предпочитают срать на головы пользователям, даже не осознавая, что насрали на голову себе. Вон из профессии таких.

Ответить | Правка | Наверх | Cообщить модератору

164. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/
Сообщение от n00by (ok), 15-Янв-24, 06:45 
> и в каждый бинарь включена своя копия реализации.

Подтверждением в виде дизассемблерного листинга не порадуете?

Ответить | Правка | Наверх | Cообщить модератору

267. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/
Сообщение от Аноним (-), 15-Янв-24, 12:56 
>> и в каждый бинарь включена своя копия реализации.
> Подтверждением в виде дизассемблерного листинга не порадуете?

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

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

Ответить | Правка | Наверх | Cообщить модератору

360. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/
Сообщение от Аноним (293), 15-Янв-24, 18:12 
А если у вас библиотека шаблонов, то методы с шаблонными параметрами тоже приходется в заголовочниках.
Ответить | Правка | Наверх | Cообщить модератору

461. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/
Сообщение от Аноним (460), 16-Янв-24, 01:18 
Шалонная часть STL - это тривиальные вещи, компилируемые в несколько процессорных инструкций. Нетривиальные находятся в libstdc++.so.
Ответить | Правка | Наверх | Cообщить модератору

522. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/
Сообщение от Аноним (115), 16-Янв-24, 14:18 
Большинство основных STL частей чисто шаблонные. Например, тот же std::map генерирует разный код для всех используемых комбинаций типов. В so-ке только темплейтнонезаисимые части и некоторые заранее сгенерированные шаблоны для типичных типов. Во время компиляции весь это код всё равно генерируется для каждого c++ исходника и дубликаты выкидываются только на стадии линковки
Ответить | Правка | Наверх | Cообщить модератору

524. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/
Сообщение от n00by (ok), 16-Янв-24, 14:26 
STL - это алгоритмы, итераторы и контейнеры, созданные Степановым и Ли. Для стандартной библиотеки лишь RTTI затруднительно реализовать как header-only, но оно и не надо в ядре. Все эти сказки про .so оставьте идеологам GPL, в ядро код и без них принимается только под этой лицензией.
Ответить | Правка | К родителю #461 | Наверх | Cообщить модератору

523. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/
Сообщение от n00by (ok), 16-Янв-24, 14:22 
>>> и в каждый бинарь включена своя копия реализации.
>> Подтверждением в виде дизассемблерного листинга не порадуете?
> Не тормози, сникерсни! Если либа в .c/.cpp и ее отдельным .so сделали
> - все три проги поюзают один shared lib, если либу так
> собрать. Будет реюз кода либы.

Тормозят пока что эксперты и внедрители Си++ в Linux. У меня стандартная библиотека для ядра header-only была 15 лет назад.

Ответить | Правка | К родителю #267 | Наверх | Cообщить модератору

663. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/
Сообщение от Аноним (-), 20-Янв-24, 12:25 
> Тормозят пока что эксперты и внедрители Си++ в Linux. У меня стандартная
> библиотека для ядра header-only была 15 лет назад.

И это все круто и офигенно - потому что что? С чисто практической точки зрения, если вы завтра перестанете существовать, вместе со своей либой - для меня изменится ну вот например что? Ах, ничего? Тогда и смысла передо мной рисоваться со всем этим - примерно ноль. Набивайте себе цену перед теми кому ваши поделия полезны, имхо. Это не я.

Ответить | Правка | Наверх | Cообщить модератору

668. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/
Сообщение от n00by (ok), 20-Янв-24, 15:28 
>> Тормозят пока что эксперты и внедрители Си++ в Linux. У меня стандартная
>> библиотека для ядра header-only была 15 лет назад.
> И это все круто и офигенно - потому что что?

Потому что ты придумал тезис "круто и офигенно", что бы приписать его мне. В надежде на что?

> С чисто
> практической точки зрения, если вы завтра перестанете существовать, вместе со своей
> либой - для меня изменится ну вот например что? Ах, ничего?
> Тогда и смысла передо мной рисоваться со всем этим - примерно
> ноль. Набивайте себе цену перед теми кому ваши поделия полезны, имхо.
> Это не я.

"Я три дня гналась за вами, чтобы сказать, как вы мне безразличны!" (ц)

Ответить | Правка | Наверх | Cообщить модератору

486. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +1 +/
Сообщение от Аноним (486), 16-Янв-24, 07:32 
>Если всё линкуется в один бинарник, то вообще может быть ошибка линковки

чудик не знал про #pragma once, но уже требует кого-то там вон из профессии :)

Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

589. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/
Сообщение от Аноним (589), 16-Янв-24, 23:13 
Э... Очевидно имелось ввиду именно линковка.

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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