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

Если бы выделить подмножество без виртуальных методов

И велосипедить vtable вручную. Какое замечательное занятие.

А если модуль ядерный написать на крестах, он работать не будет?

Как отдельный модуль будет, и те, кто не планирует апстримить часто так и делают.

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

Так это обычно, т.к. языки разные и сильно расходится культура разработки на одном и на другом. Обычное явление что опытнейшие программисты на Си когда пробуют пройти собеседование на Си++ обычно отваливаются на тестовых заданиях и им объясняют то что одна из причин их Сишный бэкграунд и на Плюсах так не пишут.

Да вообще.

предлагаю добавить в ядро поддержку сразу всех ЯП скопом.

во-первых меньше возни.

во-вторых раньше выяснится что это было нахер никому не нужно.

и случайно наткнулся на первоапрельский набор патчей для ядра

Надо было бы добавить, что это первое апреля было не в прошлом, а в 2018-ом. И тогда благодаря игнорированию оно прошло очень тихо.

Если разрешат весь сипипи, то кто нить вкорячит Вирт методы.

И собсна что? Я больше чем уверен, что сейчас там полно мест, где они эмулируются вручную в точности. Собсна, любой плагин (например, драйвер) как частный случай стратегии их неизбежно использует.

который и написал эти патчи как шутку 6 лет назад.

А,.. ОК :)

на Плюсах так не пишут

Посмотреть бы на оба варианта. Наверное там нужно писать в режиме «ООП ради ООП», тогда собес пройдёшь.

Circle

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

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

Ужасный недосинтаксис

Это вкусовщина, так про любой язык говорят. Мне вот мерзкий си не нравится и что теперь?

Мне язык не мешает писать хороший и понятный код. Другим он не мешает писать говнокод. Это не проблема языка.

GC в ядро?

Для пользовательских драйверов, в остальное можно не пущать. Это лучше, чем сегфолтящееся и дырявое говно на си.

Circle не opensource и пилится одним человеком непонятно с какой целью. Посмотри на issues у circle на гитхабе. Там автор очень неохотно на вопросы отвечает.

Я книжек по крестам практически не читал (я этим не горжусь), но может быть дело в том, что ты далеко ушел от нубства и смотришь на учебники совсем другими глазами.
Типа, чо за вода, сорцы же есть, и стандарт.

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

cppfront, но он ещё в разработке.

Claude.AI:

Here are some other notable projects that aim to improve C++ in various ways:

• C++Now Proposals - A group effort led by Bryce Adelstein Lelbach to prototype and implement experimental C++ proposals. Includes things like modules, coroutines, pattern matching etc.

• Clangd - Clang’s language server provides functionality like auto-complete, goto definition, and other IDE features to improve C++ dev experience.

• Conan - Open source C++ package manager aimed at dependency management and distribution of C++ libraries/binaries.

• CppSharp - Tools to bridge between C++ and .NET ecosystem, enabling interop between the languages.

• JUCE - Popular cross-platform GUI framework for C++ focused on improving application development experience.

• Meson - Build system designed for C++ to address shortcomings of Make/CMake. Focuses on speed and usability.

• Range-v3 - Experimental range/iterator library for C++ providing composable APIs.

• Vcpkg - C++ library manager by Microsoft, enables simplified install/integration of open source C++ libraries.

There are also some other experimental/research languages exploring C++ evolution:

• Carbon - Discussed previously, Google’s effort for a successor language.

• Corrode - Project exploring transpiling Rust to C++ to bring Rust safety features to C++.

• P0267R6 - Herb Sutter’s C++ «Syntax» experiment for a new C++ syntax.

So in summary, various efforts look to improve C++ from libraries, tools, new languages or transitioning features. But cppfront and Carbon seem the most ambitious at evolving ISO C++ itself.

Сравнительная таблица диалектов развития C++:

https://text.is/OOQ1

А как на ЛОРе отображать markdown таблицы, чтобы они правильно рендерились?

Да нет, как раз «ООП ради ОПП» маркер того что человек не очень владеет таким инструментом как ООП, за лишние сущности в тестовом задании конечно поругают.

Кстати не только от Сишников видно. Например можно понять что этот код на Си++ писал человек который до этого хорошо пропитался разработкой на Джава :) с ООП у них отлично (правильно и к месту).

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

странно что прям отдельные книги. Хотя для этого достаточно хорошей статьи формата блога, не более.

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

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

И потом достаточно прикольно применять технику шаблонов для, например, ограничения на входящие параметры в шаблонной библиотечной ф-ии, т.е. допустим ф-я имеет входящие параметры шаблонные и внутри себя может успешно работать с любыми типами, т.к. над всеми ими определены все те операции что в теле метода, но из конетекста задачи например можно передавать только типы символов и строк, или например только целочисленные. Без продвинутой техники шаблонов нужно было бы применять перегрузки ф-й, или упаси случай сишный подход - с ф-ями с разными суффиксами (соотвествующие типам), а с шаблонами код получается один (ну да пара-тройка классов хелперров в 4-6 строк, от которых в рантайме (да и в бинарнике, вангую, но кстати не уточнял этот момент) не останется и следа.

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

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

О чем вы? И о каких Плюсах? Си++ 98 и Си++14 это разные языки, не говоря уже о С++20.

Я об Epoc32/Symbian, очевидно. Других мало-мальски немаргинальных ОС написанных на плюсах в истории программирования не было.

А что до всяких там версий плюсового стандарта - напомнило всем знакомое дебильное «вы не понимаете, ЭТО ДРУГОЕ!». Нет, это не другое. Это всё те же самые плюсы непригодные для написания ядра ОС.

Зато в автоматический vtable нельзя банально засунуть константу.

Я, наверное, чего-то не понимаю про ручную реализацию (я такого стараюсь избегать), но как туда можно засунуть константу?

В плюсах надо определить список методов с virtual, и в плюсах-то их можно сделать constexpr и в каких-то ситуациях получить гарантию compile time исполнения, хотя это и редкая история.

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

Т.е. не понятно, что именно можно оптимизировать в ручном варианте, чего нельзя сделать с virtual методами и автоматической vtable.

Так ядро NT от винды же вроде на плюсах написано? Или там не правильные плюсы, а винда - это маргинальщина?

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

напомнило всем знакомое дебильное «вы не понимаете, ЭТО ДРУГОЕ!».

А мне больше напомнило человека не компетентного в том о чем он говорит.

Тупизм какой-то

Circle не opensource

Это не отменяет того, что компилятор есть и работает. Можно скачать, можно попробовать в godbolt

и пилится одним человеком

И этот человек запилил уже больше чем гугловцы с carbon

непонятно с какой целью

Цели описаны в README

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

С похмелья после праздничной новогодней недели

Он шо неделю бухал?

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

Можно конечно без ООП кодировать в стиле ООП, но зачем?
ООП C++ конечно привлекателен тем, что упрощает код, но всё же он скорее «бесплатный сыр».

Sorry за 531-й повтор суждения.
ООП C++ является лишь одним из способом работы с объектами и никак не панацея.
Иногда использование ООП вполне уместно, а иногда просто результат «джунства».

Шутка

Прения об ООП === прениям о goto.

переписать структуры вроде ioctl на классы с наследованием. Но это потеря совместимости :( поэтому такого не будет.

Компонентная модель и модель подсистем (я уж не говорю о шаблонах) давно позволяют писать на плюсах без наследования :) Плюсы — мультипарадигменный язык, примерно любой проект может использовать подмножества слабо пересекающиеся с другими.

Если разрешат весь сипипи, то кто нить вкорячит Вирт методы.

Еще о ужас начнут пользоваться эксепшонами. И в 90 % случаев ничего страшного не произойдет ;) потому что слоптимизаторы плюсов как обычно будут аргументировать древними страшилками из кривых реализаций вместо выхлопа профайлера.

Еще о ужас начнут пользоваться эксепшонами.

Шутка

Лупше «паник» с перезагрузкой компьютера.

У го уже есть форк где нормальное расставление скобок разрешили :) и что-то подсказыавет, что если дойдет до ANSI или ISO стандарта, экономисты строчек «K & R стайл» из 70х опять соснут кеглю ;)

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

писать на плюсах без наследования

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

но где же мое опохмелительное пиво

О, кстати, хорошо, что напомнили, у меня в холодильнике банка тёмного после вчерашнего осталась. Стар уже стал, всё не допиваю…

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

У многих хороших художников зачастую разный стиль, а результат всегда хорош.

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

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

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

... а в плюсовом много дресни на макросах

ИМХО Си вполне хорошо подходит для разработки ядра.
Какая необходимость есть в использовании того же C++?

С++ удобнее

Это да, но он за собой много run-time своего тянет.

Какой плюсовый рантайм тебе нужен, которого не будет в сишном ядре?

Я то при чём?
Посты о том, зачем C++ использовать для разработки ядра?

Какая необходимость есть в использовании того же C++?

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

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

Ну и что, что его поместили на godbolt. Как будто это что-то значит.

А цели очевидны - продаться кому-нибудь за большие бабки. От сюда и закрытость сорсов. Но что-то никто не клюёт. Поэтому развитие компилятора застопорилось. Там ещё даже никаких фичь C++23 или C++26 нет.

Но вообще интересно, что гугл вместо того, чтобы купить Circle начал пилить свой никому ненужный Carbon.

Я то при чём?

Ну ты же заявил, что

Это да, но он за собой много run-time своего тянет.

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

Тот же return это вовсе не окончание работы функции.
Run-time код например освобождает ресурсы.

Какие ресурсы освобождает runtime код в ядре? И для кого он это делает?

Ну и в чём отличия в освобождении ресурсов в сишке и в плюсах?

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

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

Идёт суд. Обвиняется художник в мордобое.

Судья: Зачем вы разбили нос потерпевшему?
Обвиняемый: Я художник, я его так увидел.