операционная система — разработка ядра и переполнение стека

Существует множество примеров хорошо используемых операционных систем (или их частей), реализованных на C ++ — IOKit — подсистема драйверов устройств MacOSX и IOS реализована на EC ++. Тогда есть ЭКОС RTOS — где ядро ​​реализовано на C ++, даже с использованием шаблонов.

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

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

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

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

Несомненно, использование исключений и RAII Paradigm значительно улучшит качество кода ядра — вам нужно только взглянуть на исходный код для BSD или linux, чтобы увидеть альтернативу — огромное количество кода для обработки ошибок, реализованного с gotos.

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

Однако есть несколько причин, чтобы предпочесть С.

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

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

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

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

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

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

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

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

Хотя в (ANSI) C есть что-то «честное», в C ++ есть и кое-что «честное».

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

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

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

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

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

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

Короче говоря, выбор сильно ориентированного на ООП проекта с глубокими полиморфными иерархиями выдает громкую ПЛОХУЮ ИДЕЮ, когда речь заходит о разработке ядра или любом другом сценарии с высокой производительностью.

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

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

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

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

foo.do_something();

или же:

my_class_do_something(&foo);

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