Развитие ядра и С++

Ответ 1

Это явно описано в Wiki OSDev.

В принципе, вам нужно либо реализовать поддержку времени выполнения для определенных вещей (например, RTTI, исключения), либо воздержаться от их использования (оставив только подмножество C++, которое будет использоваться).

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

Ответ 2

Существует множество примеров хорошо используемых операционных систем (или их частей), реализованных в C++ - IOKit - подсистема драйвера устройства MacOSX и IOS реализована в E C++. Затем есть ОСРВ eCOS, где ядро реализовано в C++, даже используя шаблоны.

Операционные системы традиционно наводнены примерами концепций OO, реализованных жестким способом в C. В модели устройства linux kobject фактически является базовым классом для объектов драйвера и устройства, в комплекте с DI-V-таблицами и некоторыми фанковыми механизмами, реализованными в макросах для и литье под давлением.

Ядро Windows NT имеет еще более глубоко внедренную иерархию наследования объектов ядра. И для всех соседей, жалующихся на пригодность обработки исключений в коде ядра, точно такой механизм предоставляется.

Традиционно аргументы против использования C++ в коде ядра были:

• Переносимость: наличие компиляторов C++ для всех целевых платформ. Это уже не проблема
• Стоимость C++ языковых механизмов, таких как RTTI и исключения. Очевидно, что если они будут использоваться, стандартная реализация не подходит, и конкретный вариант, используемый для ядра, требует использования. Это, как правило, является драйвером использования E C++
• Надежность API C++, и особенно проблема Хрупкого базового класса

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

Ответ 3

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

Однако есть несколько причин предпочесть C.

• Это простой язык! Там очень мало магии. Вы можете рассуждать о механическом коде, который компилятор будет генерировать из вашего исходного кода без особых трудностей.
• Это происходит довольно быстро.
• Там не так много требуемого времени выполнения; требуется минимальное усилие, необходимое для переноса этого в новую систему.
• Существует множество достойных компиляторов, предназначенных для многих различных системных и системных архитектур.

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

Кстати, Linus - не единственный разработчик ОС, имеющий сильные мнения по языкам системного программирования; Тео де Радт из OpenBSD сделал несколько цитат по этому вопросу.

Ответ 4

Для решения проблем Torvalds и других, упомянутых здесь в другом месте: В жестких RT-системах, написанных в C++, STL/RTTI/исключения не используются, и этот же принцип может применяться к гораздо более мягкому ядру Linux. Другие опасения по поводу "модели памяти ООП" или "накладных расходов полиморфизма" в основном показывают программистам, которые никогда не проверяли, что происходит на уровне сборки или структуре памяти. C++ так же эффективен, и благодаря оптимизированным компиляторам во много раз более эффективен, чем программный программист, записывающий таблицы поиска плохо, так как у него нет виртуальных функций.

В руках среднего программиста C++ не добавляется какой-либо дополнительный код сборки вместо C-кода. Прочитав asm-перевод большинства C++ конструкций и механизмов, я бы сказал, что компилятор даже имеет больше возможностей для оптимизации vs C и может иногда создавать более компактный код. Что касается производительности, довольно легко использовать C++ так же эффективно, как и C, но при этом использует мощность ООП в C++.

Поэтому ответ заключается в том, что он не связан с фактами и в основном вращается вокруг предрассудков и не знает, какой код создает CPP. Мне лично нравится C почти так же, как C++, и я не возражаю против этого, но нет никакого рационального подхода к планированию объектно-ориентированного дизайна над Linux или самому ядру, это сделало бы Linux много хорошего.

Ответ 5

Возможность записи ядра в C++ может быть легко установлена: это уже сделано. EKA2 - это ядро Symbian OS, которое было написано в C++.

Однако некоторые ограничения на использование определенных функций C++ применяются в среде Symbian.

Ответ 6

Хотя есть что-то "честное" о (ANSI) C, есть и нечто "честное", по-другому, о C++.

Синтаксическая поддержка C++ для абстрагирования объектов очень важна, независимо от того, какое пространство приложения. Чем больше инструментов доступно для предотвращения неправильного использования, тем лучше... и классы - такой инструмент.

Если какая-то часть существующего компилятора C++ не очень хорошо работает с реалиями уровня ядра, то уменьшите модифицированную версию компилятора, которая делает это "правильным" способом и использует это.

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

Тем не менее, и даже как опытный программист, я скучаю по старым временам написания на ассемблере. Мне нравится их как... C++, так и ASM... пока я могу использовать Emacs и отладчики исходного уровня (:-).

Ответ 7

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

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

Короче говоря, выбор в пользу ориентированного на ООП проекта, с глубокими полиморфными иерархиями выделяет громкий BAD IDEA, когда дело доходит до разработки ядра или любого другого сценария с высокой интенсивностью.

Конечно, все это при условии, что вы выбираете ориентированный на ООП дизайн, который отделяет C++ от C.

Однако, поскольку C++ реализует почти все функции C, нет ничего, что помешает вам избежать недостатков ООП и создать более ориентированный на данные дизайн, который может быть реализован в C++.

ИМО выражение C++ плохо для разработки ядра, потому что для большинства людей C++ почти подразумевает ООП, что плохо для сценариев с высокой интенсивностью, но C++ НЕ ЯВЛЯЕТСЯ, это не строго соблюдается ООП, это общая цель язык. При этом ориентация данных - это вопрос дизайна, его можно даже реализовать на Java, но производительность Java обычно ниже, чем C/C++.

Ответ 8

Одним из больших преимуществ C является его читаемость. Если у вас много кода, что более читаемо:

foo.do_something(); 

или:

my_class_do_something(&foo); 

В версии C явно указано, какой тип foo используется каждый раз, когда используется foo. В C++ у вас много и много неоднозначной "магии", идущей за кулисами. Поэтому читаемость намного хуже, если вы просто смотрите на небольшой фрагмент кода.