Чому операційні системи роблять матеріали низького рівня в C та C ++? Чому б не просто C ++?

На сторінці Wikipedia для Windows зазначено, що Windows написано в Асамблеї для завантажувача і перемикача завдань, а C і C ++ для підпрограм ядра.

IIRC, ви можете викликати функції C ++ з extern "C"'d блоку. Я можу отримати використання C для функцій ядра, тому чисті програми C можуть використовувати їх (як printfі такі), але якщо їх просто можна загорнути в extern "C "блок, то чому код у C?

Це здебільшого з історичних причин. Деякі частини ядра Windows були спочатку написані на мові C, оскільки 1983 рік, коли три десятиліття тому, коли Windows 1.0 був розв'язаний , C ++ ледь вийшов. Тепер ці C-бібліотеки залишаться там "назавжди", тому що Microsoft зробила зворотну сумісність точкою продажу, а переписання сумісної з помилками версії C-частин на C ++ вимагає неабияких зусиль, щоб не отримати ефективної користі.

Як зазначає більшість людей, причини є далеко не історичними, але є щось інше, про яке ніхто не згадує, і я вважаю, що люди все-таки пишуть код C для низького рівня.

C - це невелика мова в тому сенсі, що специфікація (відносно) коротка. C ++ величезна, і це заниження. Це може не мати великого значення для програміста (хоча, я думаю, це і є), але вкрай важливо, якщо ви хочете зробити офіційну перевірку . Крім того, є створені інструменти для аналізу коду С, які можуть допомогти запобігти помилкам тощо.

І це дуже важливо у вбудованому програмному забезпеченні, де вартість розгорнутої помилки надзвичайно висока порівняно з рештою галузі (порівняйте Web, де ви можете негайно застосувати виправлення до всіх користувачів). Не кажучи вже про критичні для місії програмні засоби та медичні матеріали.

Були спроби витіснити C зі свого домінуючого місця в програмуванні низького рівня з мовами, які в цьому навіть кращі, як BitC, але вони досі не мали успіху.

1. Час виконання C набагато менше.
2. Переклад C ++ на конструкції нижчого рівня менш прозорий, ніж у C. (Див. Посилання та vtables, для двох швидких прикладів)
3. З, як правило, має стійкий ABI. З ++ зазвичай немає. Це означає, що за мінімального мінімуму інтерфейс системного виклику повинен бути стилем C. Крім того, якщо вам потрібні будь-які динамічні модулі, наявність послідовного ABI дуже допомагає.

Причини не технічні. Трохи складання неминуче, але вони не змушені користуватися випадковими С, вони хочуть . Моя компанія використовує власне власне ядро, написане майже повністю на C ++, але нам не потрібно підтримувати інтерфейс C до ядра, як і більшість інших, тому що наше вбудоване ядро ​​монолітно компілюється з нашими програмами C ++. Якщо у вас є інтерфейс C, то простіше написати код інтерфейсу на C, навіть якщо це можливо використовувати extern "C"для запису його на C ++.

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

Розробники ядра часто є тими людьми, які відчувають себе щасливішими, коли з джерела відразу видно, що насправді робить код.

У C ++ є багато інших функцій, які приховують те, що код робить більше, ніж звичайний код C приховує це: перевантаження, віртуальні методи, шаблони, посилання, кидки ... C ++ також має набагато більше синтаксису, який ви повинні освоїти, щоб навіть зрозуміти C ++ код, використовуючи його.

Я думаю, що сила C ++ - це дуже потужний інструмент для створення бібліотек та фреймворків, які потім роблять розробку додатків одразу. Дуже часто розробник додатків C ++ повністю втрачається в заповнених шаблонами внутрішніх частинах бібліотеки, навіть коли він дуже компетентний у створенні програм за допомогою цієї бібліотеки. А написання права на бібліотеку C ++ є дуже складним завданням програмування, і це робиться лише для того, щоб забезпечити чудову основу на користь розробника додатків. Бібліотеки C ++ не є просто внутрішніми, вони є (або можуть бути ...) просто потужними, але простими з точки зору програмістів програми.

Але API ядра не може бути API C ++, він повинен бути мовно-агностичним API, тому більшість приємних речей у C ++ не можуть бути безпосередньо використані в цьому інтерфейсі. Крім того, ядро ​​насправді не поділяється на "бібліотеку" та "додаток" частини, розроблені самостійно, з більшими зусиллями логічно збираючись в одній бібліотеці, щоб спростити створення маси додатків.

Крім того, безпека та стабільність є більш критичними всередині ядра, і віртуальні методи набагато більш динамічні, і тому їх набагато складніше виділити та перевірити, ніж звичайні зворотні виклики чи інші механізми, подібні С.

Коротше кажучи, хоча ви, звичайно, можете писати будь-яку програму C, включаючи ядро ​​як C ++, більшість потужностей C ++ недостатньо використовується в ядрі. І багато хто стверджує, що засоби програмування повинні заважати вам робити те, чого не слід робити. C ++ не хотів.

Bjarne Stroustrup, в інтерв'ю в липні 1999 року :

Жодна з цих мов не була докорінно різною або кардинально кращою, ніж інші сучасні мови. Однак вони були досить хорошими і користувались удачею та соціальними факторами

C за своєю конструкцією дуже низький рівень мови. Це в одному кроці від асемблера; знаючи чіпсет, на який ви орієнтуєтесь, ви можете, маючи невеликі знання, вручну "скласти" C в ASM. Цей тип "близької до металу" мови є ключовим для високих рівнів оптимізації (для продуктивності, ефективності пам'яті тощо). Однак, оскільки це так близько до металу, з цією мовою ви не отримаєте багато; це процедурна, не об'єктно-орієнтована мова, і, отже, робота з такими конструкціями передбачає багато кодового коду для створення та використання багатозначних конструкцій у пам'яті.

C ++ - це "C one better", додаючи ряд зручних у використанні функцій, таких як динамічне розподілення пам'яті, вбудована маршалізація структури, велика бібліотека заздалегідь визначеного коду тощо за рахунок певних втрат ефективності (все ще набагато краще ніж середовища керованого виконання). Для середнього кодера переваги значно переважають недоліки в областях кодової бази, які не потребують анально-ретентивного контролю розподілу пам'яті тощо.

Поєднання двох - досить традиційне; ви використовуєте C для написання найбільш критичних для продуктивності пам'яті областей бази даних, з якими потім можна працювати більш абстраговано, використовуючи виклики методів з коду C ++, які можуть бути більш елегантно організовані та розроблені, ніж виконавці uber , uber-oogly оптимізований код C.

Можливо, з C ви витрачаєте більшу частину часу на роздуми про проблему, про яку йдеться, і про те, як кодувати рішення. У мові C ++ ви думаєте про C ++ та його безліч особливостей, функцій та незрозумілого синтаксису.

Крім того, у багатьох магазинах C ++ ваш код контролюється "поліцією моди", яка захоплена останнім набором моделей дизайну, або останніми нерозбірливими вимовами великого бога Струструпа. Гарний код стає більш цінним, ніж робочий код, пошук використання останнього набору шаблонів Boost захоплюється більше, ніж пошук робочого рішення для бізнесу.

Мій досвід полягає в тому, що для всіх розумних функцій і чистоти OO C ++, кодування в простому C робить роботу швидше і ефективніше.

Можливо, що частини C не дуже добре переносяться на компілятор C ++, який використовується для частин C ++. Можливо, код C чутливий з компілятором C таким чином, що переривається з компілятором C ++.

Якщо у вас є якісний компілятор C ++, майже немає підстав змішувати C і C ++ в проекті. Майже.

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

Я думаю, що у вас це відбувається назад - extern "C"блок забезпечує використання конвенцій виклику C для всіх функцій блоку. Таким чином, ви можете викликати чисті C функції з C ++, а не C ++ функції від C. Незалежно, я думаю, що причина, що люди використовують і C, і C ++, полягає в тому, що багато бібліотек низького рівня написано за допомогою C, і простіше використовувати щось, що вже існує (і, імовірно, налагоджено та оптимізовано), ніж писати своє. OTOH, C ++ пропонує безліч приємних функцій високого рівня, з якими люди воліють би працювати, тому вони використовують це для решти.

Існують різні рівні вбудованих платформ, що використовують С як мову програмування (звичайно, це ваша свобода використовувати мову складання в будь-який час)

Для "рівня" я кажу про рівень внутрішнього SRAM та ROM для системи.

Ці платформи іноді обмежені ресурсами (наприклад, деякі 8051 платформи мають лише 128 байт користувача SRAM).

Підтримувати динамічний розподіл пам'яті з таким невеликим об'ємом для оперативної пам’яті безглуздо. (новий / видалити) або навіть malloc у C.

Одним з головних удосконалень від C до C ++ є об'єктно-орієнтована парадигма. C ++ підходить для програмного забезпечення з більшим відбитком пам’яті

але не у вбудованій прошивці, яка має обмеження розміру до 32 КБ. (наприклад, у 16-бітній платформі MCU)

Немає необхідності мати компілятор C ++, який, як правило, складніше, ніж компілятор C. (принаймні провайдери SDK не будуть це робити).

Насправді я навряд чи можу знайти компілятор C ++ на 32-бітній платформі ARM7.

Це просто не варто складності

У деяких 8051 (8 біт): 1 Мб ROM, 128B оперативної пам’яті

TI MSP430 (16 біт): 32 КБ ПЗУ, 4 КБ ОЗУ

32-розрядний процесор Cortex ™ -M3 CPU ST Microelectronics ARM (STM32F103T4): 16 або 32 Кбайт флеш-пам'яті, 6 або 10 Кбайт SRAM

Я бачу пару можливих причин:

• C трохи ефективніше порівняно з еквівалентом C ++.
• Деякі бібліотеки, якими вони користуються, написані на С.
• Вони використовують деякі частини ядра Linux, які написані на С.

Відредаговано: Як виявляється, третій аргумент не відповідає дійсності (див. Коментарі).

Тому що C, мабуть, краща мова, ніж C ++. А тому, що частина коду була написана ще до того, як C ++ став популярним, і люди не мали причин замінити його.

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