LINUX.ORG.RU

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

 ,


1

5

В списке рассылки разработчиков ядра Linux возобновилось начатое шесть лет назад обсуждение перспектив использования современного кода на C++ в ядре Linux, помимо нынешнего применения языка Си с ассемблерными вставками и продвижения языка Rust. Изначально тема разработки ядра на C++ была поднята в 2018 году инженером из Red Hat, который первого апреля в качестве шутки опубликовал набор из 45 патчей для использования шаблонов, наследуемых классов и перегрузки функций C++ в коде ядра.

С инициативой продолжения обсуждения выступил Ганс Питер Анвин (Hans Peter Anvin), один из ключевых разработчиков ядра в компании Intel и создатель таких проектов как syslinux, klibc и LANANA, разработавший для ядра Linux систему автомонтирования, реализацию RAID 6, драйвер CPUID и x32 ABI. По мнению Анвина, который является автором многочисленных макросов и ассемблерных вставок в ядре, с 1999 года языки C и C++ значительно продвинулись вперёд в своём развитии и язык C++ стал лучше, чем С, подходить для разработки ядра операционных систем.

Возможности, для которых ещё недавно приходилось привлекать специфичные GCC-расширения, теперь легко реализовать на стандартном C++, и во многих случаях использование C++ позволит улучшить инфраструктуру без глобального изменения кода. В качестве минимальной упоминается использование спецификации C++14, которая включает необходимые средства метапрограммирования, а в качестве желаемой - использование спецификации C++20, в которой появилась поддержка концепций, способных исключить появление многих ошибок.

Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра и не позволяет постепенно переписывать код (в случае языка С++ можно по частям переводить код с языка C, так как С-код можно компилировать как C++). В поддержку использования С++ в ядре также выступили Иржи Слаби (Jiri Slaby) из компании SUSE и Дэвид Хауэллс (David Howells) из Red Hat.

>>> Подробности

★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от zx_gamer

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

Что делает функция все равно таки надо прочитать.

На C++98 можно написать любой контейнер

Можно. Но с foreach с ним будет работать гораздо удобнее.

если немного подумать, то многие решения можно сделать логичнее и красивее

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

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от AntonI

foreach реализуется несложным макросом (посмотри на Boost Foreach), добавлять его в язык вовсе не обязательно.

zx_gamer ★★★
() автор топика
Ответ на: комментарий от zx_gamer

В стандарте С++98 без явного указания типа итератора, при условии что его нельзя явно получить из контейнера?

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от AntonI

Просто разные стили программирования…

Если мы пишем в процедурном стиле, то объявление функции это ТЗ на ее написание, и конечно, хотелось бы, чтобы ТЗ было максимально четким – что получает, что возвращает, имя функции описывающее ее суть, комментарии если этого всего недостаточно… Тут важно, чтобы все типы были явно определены. Эту часть можно воспринимать как часть проектирования архитектуры программы.

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

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

PS: это к ветке дискуссии «Я обожаю когда auto – возвращаемый тип.»

soomrack ★★★★★
()
Последнее исправление: soomrack (всего исправлений: 1)
Ответ на: комментарий от sabacs

Меня всегда безумно радует, когда кто то пытается натянуть правила своего манямирка на весь окружающий мир!

AntonI ★★★★★
()
Ответ на: комментарий от soomrack

Все так. Но изначально, в моем примере, про auto как про возвращаемое значение речь вообще не шла:-)

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от AntonI

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

sabacs
()
Ответ на: комментарий от sabacs

Дяденька, Вы вот сейчас на полном серьезе заявляете что видели ВСЕ серьезные проекты? И что нет областей где подобные идентификаторы являются не то что допустимыми - строго обязательными?!

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

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от AntonI

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

zx_gamer ★★★
() автор топика
Ответ на: комментарий от zx_gamer

Нет. Это можно сделать только в самом примитивном случае за счёт кучи умолчаний (не писали Вы сложных контейнеров с разными вариантами итераторов, хехе). Странно что это неочевидно.

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

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

И что нет областей где подобные идентификаторы являются не то что допустимыми - строго обязательными?!

обязательными они не являются примерно нигде. Допустимыми - разве что внутри функций, осуществляющих внутри себя матан по заданным формулам, в которых эти вот все v/u/f/μ/A имеют смысл.

arkhnchul ★★★
()
Ответ на: комментарий от arkhnchul

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

В таких вещах код должен абсолютно точно соответствовать бумажке, иначе потом фиг ошибку найдёшь. И длинные идентификаторы делают такие вещи нечитабельными - там и так много букв.

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

Не писали Вы сложных контейнеров с разными вариантами итераторов, хехе

Интересно даже, что это за АТД такой.

zx_gamer ★★★
() автор топика
Ответ на: комментарий от AntonI

Ваше самомнение просто зашкаливает, вкупе с неуклюжими попытками поставить диагноз по интернету
AntonI

herra loistaa taas...

untitl3d
()
Ответ на: комментарий от AntonI

В таких вещах код должен абсолютно точно соответствовать бумажке, иначе потом фиг ошибку найдёшь.

Ну это уже просто неосиляторство. :)

sabacs
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.