Разработка ядра и C ++

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

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

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

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

foo.do_something(); 

или:

my_class_do_something(&foo); 

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