Дискуссия об использовании языка C++ для разработки ядра Linux

движок от трактора не влезит в мою «Оку», так что нафиг эти трактора нужны?!

Вряд ли ты имел в виду именно это, но если движок от трактора не влазит в Оку, то не нужно его туда пихать. Даже более того, если движок от Волги, после обработки напильником, всё-таки влазит в Оку, даже тогда не факт что его имеет смысл туда ставить, возможно достоинства движка Волги будут бессмысленны в Оке.

чего? Пример в студию!

Пример чего? Деструктора, освобождающего память? Ну ок:

~MyClass(){
   delete ptr;
}

вопрос в соотношении. Без асма тоже невозможно написать платформозависимую часть ядра, но это не значит, что сишка бесполезна.

Мы явно говорим о разном. Дело не в том, что плюсы не нужны потому что есть ассемблер, дело в том, что фича плюсов теряет свою ценность, так как дублирует уже существующую фичу, которую удалить нельзя.

Ведро, как почти любая сложная система, нуждается в механизме динамического вызова. И он реализован на языке C. Использование аналога из плюсов сомнительно: нужно либо сишную реализацию делать совместимой с плюсовой (а она, если не ошибаюсь, не документирована), либо иметь 2 несовместимые реализации одного и того же, одну для того что может вызываться извне, другую для внутреннего применения. Это создаст путаницу, которая не компенсируется небольшой пользой от наличия внутри плюсов встроенной реализации.

нет, в итоге остаётся очень толстый наброс от тебя

Речь вообще-то не о том что твоя любимка - говно, а о том, оправдано ли включение плюсов в ядро. В уже существующий проект написанный на C. Речь не о переписывании всего на плюсы. В таких условиях самые вкусные черты плюсов окажутся неиспользуемыми, останутся только C с классами. А имеет ли это всё хоть какой-то смысл? Ну явно нет.

Не надо паники, буст и прочее никто добавлять не будет. Исходники gcc перевели с си на с++ и ничего страшного не произошло.

у С++ всегда будет проблема утверждения, что это не С с классами.

и конечно множественное наследование, виртуальные функции, шаблоны и исключения принесут массу рабочих мест

Без неявных аллокаций? Да.

В уник передаётся уже выделенная память, в большинстве случаев она будет явно выделена в его же конструкторе. Можно, конечно, через обёртки делать, но если это неявное выделение памяти, то их можно смело запретить.

Сам по себе unique_ptr не нужен, он ценен как член некоей структуры.

Создать ресурс где-то в произвольной точке функции и гарантированно его освободить, без возни с goto final и ручной очистки и без нестандартных расширений - это не нужен? Ты из свято верующих в собственную непогрешимость?

А код драйвера не так уж обычно сложен, чтоб реально выигрывать что-то на плюсах

Это пока он не утекает. Ты получаешь автоматическое слежение за ресурсами без накладных расходов. И ты же это отвергаешь, т.к. деды руками чистили, нечего и начинать.

особенно с «рантаймом».

Какой такой рантайм ты тут нашёл, которого нет в сишке?

так как дублирует уже существующую фичу, которую удалить нельзя.

Ядро гарантирует стабильное api для юзерспейса. Всё остальное регулярно меняется. Понятно, что это не делается по щелчку пальцев, но это всё возможно, если будет приносить пользу.

Речь не о переписывании всего на плюсы. В таких условиях самые вкусные черты плюсов окажутся неиспользуемыми, останутся только C с классами. А имеет ли это всё хоть какой-то смысл? Ну явно нет.

На деле имеет. Даже если примут минимальный вариант плюсов даже без плюсового манглинга всё равно останется более строгая система типов. Это позволит избавляться от void* и дрисни на макросах. Да, происходить это будет не быстро, в каких-то кусках останется навсегда, но там, где идёт активная работа или где выявляются ошибки код будет улучшаться. Одного этого уже достаточно.

Дададад.

Это какая-то языковая дискриминация! Почему только Сишечка, Ассемблер и Rust?! Почему нельзя использовать Java, Python, JS и Brainfuck?!

Это какая-то языковая дискриминация!

Да.

Офигительно он читаем.

template < class T >
class std::enable_if< Some_struct, std::is_fundamental<T> > :: type
{
};

И это классический прием, без всяких хаков.

А можно, например, переопределить operator,() как в Boost assign для инициализации контейнеров:

std::vector < int > my_vec;
my_vec += 1,2,3,4,5;

И это все работает в C++98, а знаете что можно написать в более поздних стандартах?

Ядру после этого окончательный трындец. Там даже в сишном коде черт ногу сломит, что будет, когда там будет C++?

Рантайм жирный ещё.

Нет рантайма, если не использовать RTTI (dynamic_cast).

Ребят, это вообще нормально, что я ничего не понимаю из того, что вы тут пишете? А ведь у меня пять звёзд … [facepalm.gif]

Вот. Умные мысли всегда радуют.

(с крестами это произошло после внедрения многопоточности?)

Окончательное, наверное, да. Но даже C++98 хорошо так сел на STL и выкорчёвывание его стоит хоть и не катастрофических, но не нулевых усилий.

Да, где-то в толксах была, говорят.

знаете что можно написать в более поздних стандартах?

В более поздних стандартах код гораздо более читаемый, и от sfinae тоже ушли.

Били копыта. Пели будто:
— Гриб.
Грабь.
Гроб.
Груб. — 

Угробят ядро, в этом уже нет никаких сомнений.

«Я утратил всякие надежды относительно будущего нашей страны, если сегодняшняя молодежь завтра возьмет в свои руки бразды правления, ибо эта молодежь невыносима, невыдержанна, просто ужасна.» — Гесиод, ок. 720 до н.э.

Офигительно он читаем.

Да:

template <class T>    
concept Fundamental = std::is_fundamental_v<T>;    
    
template <Fundamental T>    
struct Struct {    
    T t;    
};    

Явно лучше, чем

void func(void* arg1, void* arg2, void* arg3) {
}

а знаете что можно написать в более поздних стандартах?

Учитывая, что в сишке можно написать #define true false абсолютно не важно, что можно написать на плюсах. И один и другой язык позволяют написать лютой забористой херни, и люди так делают.

Но плюсы в отличии от сишки позволяют писать хороший, производительный и читаемый код. А дальше уже всё от программиста зависит, захочет ли он воспользоваться этой возможностью.

и от sfinae тоже ушли

Это неправда. Библиотеки, как правило совместимы даже с C++98, поэтому там ничего нового нет и не будет.

В более поздних стандартах код гораздо более читаемый

Не надо рассказывать сказки. Стандарт вырос еще на две пачки бумаги в толщину. Можете открыть https://cppquiz.org и наглядно убедиться, насколько «очевидный» код в C++17. И он никогда не сравнится с Си по простоте.

Хотя нет, рантайм еще есть при использовании виртуальности, но он почти нулевой.

void* arg1, void* arg2, void* arg3

Когда это такое надо? void* используется сравнительно редко.

void* используется сравнительно редко.

$ rg 'void\s*\*' | wc -l
97504

Ну да, действительно.

Хотя нет, рантайм еще есть при использовании виртуальности, но он почти нулевой.

С чего вдруг это рантайм? А вручную свелосипеженный vtable на сишке это тоже рантайм?

Библиотеки, как правило совместимы даже с C++98, поэтому там ничего нового нет и не будет.

Откройте уже доки и посмотрите сколько новых методов появляется с каждым новым стандартом в STL.

Не надо рассказывать сказки

До до

for(blabla::iterator I=C.begin(); I!=C.end(); ++I)...

for(auto I=C.begin(); I!=C.end(); ++I)...

for(auto I: C)...

Раст монстр только кажущийся. Как показала одна статья на Хабре(понимаю что кто-то на этот ресурс неровно дышит), там можно вполне себе достичь минимализма сишечки, т.е. отрубить всё и вся.

По поводу того, почему же тянут всякое в ядро, ответ простой - людям надоело писать на сишечке, опасаясь при неловком движении выстрелить себе в тестикулы.

Впрочем в случае плюсов тоже не вижу в них смысла в ядре. По сути будет та же сишечка, вид сбоку.

Если тащить C++ в ядро, там надо отключать RTTI,

+1

исключения,

+1 (хотя я их и люблю)

выбрасывать стандартную библиотеку и STL,

+1

те же строки переписывать заново или брать готовое, независимое от стандартной библиотеки и контейнеров.

Строки тоже выбрасывать. Сишные строки на стеке вполне себе рулят. Разве что 0-terminated можно было бы подумать заменить на что-то типа std::string_view, но учитывая что они торчат наружу в API, смысла в этом примерно 0.

А вот откуда тут взялись некоторые, топящие за выкидывание ООП – зогатко природы. Видимо там, откуда они вылезли, модно вручную vtables эмулировать.

Корневой конфиг nginx объявлен ЕМНИП как void****. Вот блин меня разорвало. В итоге так и не разобрался до конца, что-то методом тыка по сорцам наскрёб, чтобы заработало то, что мне нужно.

Вообще, void* это по сути банальная динамическая типизация. Нечитабельный и непроверяемый компилятором полиморфизм. Говно собачье, в общем. А другого полиморфизма в сях у меня для вас нет: его там вообще нет. (Ну разве что можно указатель на функцию в другую функцию передать. А два указателя на две функции – дык это уже ООП-интерфейс.) Вот и пердолятся убогие, и в своём убожестве поливают говном язык, где он есть. На плюсях я бы нарисовал иерархию классов, может даже без виртуальных методов – т.е. без vtable, с нулевым рантайм-оверхедом, чисто ради читабельности – и вместо void* написал бы BaseClass*. Ну и кастовал бы через static_cast. Ещё и покомпактней рантайм бы вышел, с такой-то информацией у компилятора.

Во, точняк:

struct ngx_cycle_s {
    void                  ****conf_ctx;

Деды на Си писали и городили ООП на чистом Си,

Деды и зад подорожником вытерали, но ты же так не делаешь? Надеюсь...

Существенный минус - это то, что c++ компиляторы работают гораздо медленнее чем компиляторы си, разница легко может быть в десятки, а то и сотни раз.

Вы же не думаете, что они тратят время на майнинг биткойна?

Деды и зад подорожником вытерали, но ты же так не делаешь?

Со спущенными штанами сложно найти подорожник в наше время. Особенно в центре города.

Чем больше используется разных штук, тем тяжелее это всё переносить на новые архитектуры. А впереди стремительный прогресс китайских процессоров.

Ядро настолько прибито к gnu тулчейну, что вряд ли реализация нужных фич для c++ будет проблемой, всё равно компиляторы будут ограничиваться gcc и мимикрирующим под него clang.
Rust создаёт куда больше сложностей, но даже там достаточно наличия порта llvm под таргет по идее

Значит, цель именно такая — угробить.

инкапсуляция, динамический полиморфизм, RAII, шаблоны, constexpr

RAII без исключений смысла не имеет. Точнее, невозможен.

Шутка

Как пpовожают C++
Совсем не так как Си

Си бурливые воды
Hе то что template в два pяда

Как ни суди волнений больше
Ведь ты уже не на земле

Как ни pяди pазлука дольше
Когда плывешь на C++ в никуда

Флуд флуд кpугом вода
Вода вода шумит вода

Хоть массово увидят люди.

Шутка

Ага, выйдут на демонстрацию с транспорантами «Не дадим в обиду C++», ...

Товарищи флудильщики! "Физики" с кандидатами!
Замучились вы с иксами, запутались в C++!

Сидите, разлагаете флуд на атомы,
Забыв, что разлагается картофель на полях.

Из гнили да из template бальзам извлечь пытаетесь
И флудите в тредах по десять раз на дню.

Ох, вы там дофлудитесь! Ох, вы довыпендриваетесь,
Пока сгниет, заплесневет картофель на корню!

Автобусом до Сходни доезжаем,
А там — рысцой, и не стонать!
Небось Си все вы уважаете,
Когда с сольцой его намять!

Вы можете прославиться почти на всю Европу, коль
С транспорантами в треде проявите свой патриотизм.

А то вы всем кагалом там набросились на Си,
Rust ножами режете, а это — бандитизм.

Автобусом к Тамбову подъезжаем,
А там — рысцой, и не стонать!
Небось Си все вы уважаете,
Когда с сольцой его намять!

Товарищи ученые, флудильщики драгоценные,
"Физики" ненаглядные, любимые до слез!

Ведь лягут в землю общую остатки наши бренные,
Core Linux все едино: апатиты и навоз.

Так приезжайте, милые, рядами и колоннами.
Хотя вы в форуме все там ФИЗИКИ и нет на вас КРЕСТА,
Но вы ж треде все задохнетесь, за флудом, -
А здесь места отличные, воздушные места!

Товарищи ученые! Не сумневайтесь, милые:
Коль что у вас не ладится — ну, там, не тот аффект, -
Мы мигом к вам заявимся с лопатами и с вилами,
Денечек покумекаем — и выправим дефект.

RAII без исключений смысла не имеет. Точнее, невозможен.

Имеет и возможен.

Как? Пустой конструктор и метод bool init()?

RAII это не про конструктор, а про деструктор. Буквально первоочередное назначение RAII это избавиться от костылей вроде goto final и от любого другого ручного управления памятью.

Произошло, теперь только стандартом не ниже C++11 собрать можно. А раньше любым компилятором, любой версии.

Ну а конструктор и выделение памяти при отсутствии исключений как таковое не меняется. Выделил - проверь, что выделилось. Тот же код, что и в сишке.

Использую Visual Studio 2013 и non promlem при разработке API.

«Бальзам» из стандартов C++ всё время извлечь пытаются, забыв, что рулит всем алгоритм.

А теперь возьми gcc 3.3.6 или Watcom C

Берите, что хотите.
Главное не забывайте, что рулит всем алгоритм, а не «надувание щёк стандартами».

Бессмысленный трёп. Си++ – такой же устаревший хлам как и Си.

Меня-таки как раз исключения в конструкторе интересуют. Например, при открытии файла. С деструктором наоборот всё понятно: он noexcept. А если вместо исключения нужен отдельный init, возвращающий ошибку, то как минимум возникает вопрос: а компилятор (LTO) достаточно умён, чтобы увидеть, что после конструктора ВСЕГДА вызывается init, и удалить код инициализации полей по умолчанию? А как максимум, RAII расшифровывается не про деструктор. :)

Не то что новомодная ржа: ни ООП, ни исключений. Ваше замечание будет актуально лет (десятилетий? веков?) через даже не знаю сколько, на выходе из надвигающихся тёмных веков. А нынешние хипстеры один хрен ничего стоящего родить не смогут.

ни ООП, ни исключений

Это имена идолов?

Звёзды – это про флудерастию, а не про понимание ЯП каменного века.

Слушаю шас https://www.youtube.com/watch?v=Vm4-ar_wqWA&ab_channel=EmersonJuliani-Mús... Elton Jo.h.n - 18 Sucessos

Супер!

Это удобные вещи. Про жопу подорожником тут выше не вам отвечали?

Исключения в c++ — это как вытирать жопу наждачкой