В ядро предлагают добавить поддержку C++

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

Какой такой рантайм?

Ты сказал, что плюсы тащат за собой много своего рантайма, подразумевая, что сишка этого не делает. Иначе эта фраза бессмысленна.

Переменные в си и плюсах создаются и освобождаются одинаково. Единственное отличие в том, что в сишке освобождение нужно указывать руками (по-крайней мере без нестандартных расширений) и про это можно забыть. В остальном сгенерированные инструкции будут практически идентичны, просто потому что один и тот же компилятор делает одно и тоже действие.

А главное не понятно, почему ты код, освобождающий память считаешь рантаймом. Это же не managed языки и gc там нет. Этим занимается обычный пользовательский код.

В общем какой такой свой рантайм притащат в ядро плюсы, который не притащит сишка, всё ещё не понятно.

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

Потому, что для int Variable; память выделяет не программист и освобождает её не программист.

И в сишке, и в плюсах для int Variable память вообще не выделяется. Двигается указатель на стёк и на каком-то офсете от этого указателя кусок памяти назначается под эту переменную (а весьма часто сразу под несколько переменных). И происходит это в плюсах и в сишке абсолютно одинаково, ибо компилятор один и тот же и делает одно и тоже (по идее даже в плюсовых корутинах это делается так же, только стёк по особому выделяется).

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

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

За шкафом. man композиция и агрегация. Позволяет решать те же задачи что и наследование, только без развесистых иерархий, и т.д. родовых проблем ООП. Одепты ООП выдумывают броские аббревиатурки типа SOLID и вагоны «паттернов» с пересекающимся функционалом, чтоб решать проблемы... которых не было до ООП, вместо признания что ООП нужно не везде, а местами — «дуинг ит вронг», особенно там где нужны обобщенные типы, а не иерархии наследования, за что еще Степанов(создатель STL) их выстебал.

Это понятно (в простейшем случае достаточно использования стека).

Так и какой такой свой рантайм плюсы тащат за собой в ядро, который не тащит сишка? Я так и не понял.

Знаете для чего нужно устанавливать разные версии «Redistributable Package» для разных версий C++ фирмы Microsoft?

Знаю. Не для разработки ядер ОС.

Вы хотите сказать, что чистый код на C++ не влечёт за собой при кодогенерации никакого специфичного использования run-time?

Для 2 + 2 всё ok.

Скорее всего C++ вполне годится при разработке ядра.
Но вот для использования rust в ядре почему-то исследование проводилось ...

Вы хотите сказать, что чистый код на C++ не влечёт за собой при кодогенерации никакого специфичного использования run-time?

Хочу сказать, что никакой специфичный для плюсов рантайм в ядро ты просто не притащишь. Для ядра тебе придётся делать свой ядерный рантайм, проводящий какую-то первичную инициализацию. И этот рантайм для си и для плюсов будет одинаков.

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

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

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

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

Пофиксил, не благодари.

Да не «копал» этот вопрос, но и утверждать что non problem тоже «не очень».

Ты можешь написать ядерный модуль для линукса с кодом на плюсах и самостоятельно убедиться.

Ладно Дружище, в основном Ты прав, что для обсуждения этого вопроса пока не готов (не копал).
Просто Redistributable Package «навеяли» суждения о том, что C++ таки имеет свою run-time специфику.

https://gcc.gnu.org/onlinedocs/gccint/Run-time-Target.html

...

Поиск типа «gcc C++ run-time».

Имеет. Так же как и у сишки рантайм есть. Просто это не применимо для bare metal.

Так ядро NT от винды же вроде на плюсах написано?

Нет, оно написано на чистейшей сишечке. Неужто так сложно какой-нибудь radare2 запустить и посмотреть, вместо того, чтобы какой-то маркетоидный бред тиражировать?

Т.е. для как минимум не менее сложных задач чем ядро ОС и драйвера, Си++ подходит

Для задач с другой спецификой С++ подходит. Для ОС и драйверов - нет. Попытки использовать С++ для ОС и драйверов в угоду моде и всяким дебильным «good programming practices» были и абсолютно все - провалились. Для уя С++ и прочее ООП вполне годится. Потому его там чаще всего и используют. В ОС, драйверах, всяких числодробилках, эмбеддед и пр не годится. Поэтому его там не используют.

В конце-концов, по-уму, только программист может и должен решать какой именно язык ему использовать для решения той или иной задачи. А не всякие сектанты или манагеры.

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

Т.н. «индустрия» выбирает не то, что реально нужно для решения задачи, а то, про что тупорылые менеджеры в каких-нибудь тупорылых книжонках и статейках прочитали. Если завтра всякие пропагандисты «good programming practices» начнут про ниэпическую крутизну форта для приложений энтерпрайз уровня рассказывать, то вся эта сраная индустрия, которая не произвела вообще ничего пристойного в смысле высот программистского искусства за всю историю своего существования и место которой в помойке ещё со времён пузыря доткомов, тут же ринется переписывать своё дерьмо на форте.

Любые попытки подходить к программизму с точки зрения манагерства, маркетинга и «programming practices» сектантства никогда не заканчивались ничем кроме производства всё более и более убогой блоатвари. Результат этих усилий - налицо.

Это вовсе не плюсы тащат за собой рантайм. Нет особых технических проблем написать bare-metal на плюсах. Можно даже сделать это красиво и очень ООПшно. Проблема в том, что это любители плюсов тащат ненужный рантайм и без какого-нибудь boost уже не способны ничего написать, уж не говоря о libstdc++.

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

вместо признания что ООП нужно не везде

А кто-то утверждал, что ООП нужно везде? Каждой задаче – свой инструмент. А утверждения «ООП нужно везде» и «ООП вообще не нужно» одинаково идиотичны.

Кэп, ты?

А что, по аватарке не понятно?

А должно? Спать иди.

Только после вас.

Сложнее поддерживать и проще писать волшебный говнокод.

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

Во-первых, библиотеки не являются рантаймом. М.б. какие-то из них могут требовать чего-то типа rtti, что можно считать рантаймом, но любителей притащить такое в bare metal я пока не встречал и сомневаюсь, что встречу. Такое и в прикладных плюсах никто не любит.

Во-вторых, в чём проблема притащить на железку какие-то части буста, типа интрузивных контейнеров, или какие-то части stl, типа std::array или std::string_view? В чём смысл велосипедить их самостоятельно? А если есть аллокатор и ты не боишься исключений, то в чём проблема в std::vector или std::string? То, что ты сам навелосипедишь будет чем-то лучше?

Ну и последнее, я периодически пишу на плюсах прошивки для мк и как-то не встречал описанного тобой поведения, скорее наоборот, люди опасаются тащить что-то готовое, зато велосипедят с удовольствием.

В общем актуальность описанной тобой проблемы сомнительна.

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

Сложно сказать, что это нормальные программисты. Всё-таки нормальный программист не любит делать лишние действия и понимает, что он может ошибиться. Соответственно чем строже проверки в языке, тем комфортнее нормальному программисту, как минимум до тех пор, пока проверки не накладывают бессмысленных ограничений и не выдают кучи false positive.

А сишка в отличие от плюсов, фактически требует type erasure через void* и макросов, что приводит к тому, что компилятор может собрать вообще всё, что угодно.

Если программисту без разницы, писать на сишке или на плюсах, то скорее всего он свято верит в собственную непогрешимость и нормальным его назвать сложно.

Т.е. количество роутеров, поддерживаемых свежей openwrt, опять уменьшится в 2-3 раза...

Openwrt собирает ядро не gcc? Или как плюсы на это могут повлиять?

Хочу сказать, что никакой специфичный для плюсов рантайм в ядро ты просто не притащишь

вообще rtti при желании можно притянуть, но его в приложения-то не всегда тянут

Попытки использовать С++ для ОС и драйверов в угоду моде и всяким дебильным «good programming practices» были и абсолютно все - провалились.

их не было

вообще rtti при желании можно притянуть, но его в приложения-то не всегда тянут

Ну да. И к тому же довольно сложно придумать, зачем rtti в ядре в принципе может понадобится.

Я хз, когда последний раз тыкал gcc, hello_world.cpp с точно таким же кодом, как в hello_world.c, занимал в разы больше места

Интереса ради, а почему в C++ без iostream и cout?

hello_world.cpp с точно таким же кодом, как в hello_world.c

понятно?

Ну тогда нужно пояснение - зачем тут C++ - если писать на чистом Си.

А понял/увидел/перечитал - тогда мой камент мимо.

Плюсовый приветмир даже в плюсовом стиле занимает столько же, сколько сишный: Выпуск Bluetuith v0.1.8 (комментарий)

Для плюсового - 1,8 МБ, хехе (с того же треда - твое).

Так это static

Это понятно, но это больше отражает реальность кмк.

Это отражает размер iostream vs printf, не более. Да, размер iostream больше, вряд ли кто-то удивился.

Опять же, если компилировать один и тот же код, то и размер будет одинаковым, в том числе и при static-сборке.

Это да, но плюсы же берут не для того что бы на Си писать.

Каким образом из этого следует необходимость использования iostream или stl?

Из этого никаким, но на вопрос ты так и не ответил.

Этого не хватало…

Надеюсь, у Линуса башка болит достаточно сильно, чтобы отказать в притягивании этого геморроя.

но на вопрос ты так и не ответил.

Так ты вопрос и не задавал, это утверждение было.

Естественно, плюсы берут для того, чтобы писать на плюсах, а не на сишке. Но на плюсах можно писать и без stl (и тем более без iostream), если stl по каким-то ограничениям тебе не подходит.

Или можно взять ограниченную версию stl, типа freestanding.

И при этом это будет всё ещё в разы лучше сишки. Что тут может быть не очевидно?

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

Ну т.е. писать предлагается на каком-либо подмножестве плюсов.

В рамках ядра, естественно, писать нужно на каком-то подмножестве. Более того, в рамках ядра и на Си сейчас пишут на подмножестве и libc, входящая в стандарт Си там сильно порезана.

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

Ну хз насколько это необходимо и оправдано.

Необходимого в этом, очевидно, нет. Ядро и сейчас вполне жизнеспособно.

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