Линус Торвальдс против C++: Почему ядро Linux остается на C?

МЕНЮ


Главная страница
Поиск
Регистрация на сайте
Помощь проекту
Архив новостей

ТЕМЫ


Новости ИИРазработка ИИВнедрение ИИРабота разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика

Авторизация



RSS


RSS новости


2026-01-13 12:29

разработка по

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

Разбираем основные аргументы Линуса (и почему они имеют смысл в context of kernel development).

1. Исключения (Exceptions) - зло для ядра

В C мы проверяем коды возврата. В C++ исключение может вылететь откуда угодно.

Проблема: Недетерминированность. Для ядра с 30 млн строк кода это ад отладки.

Риск: Если МРТ-сканер или система управления полетами "выбросит исключение" и упадет, последствия будут фатальными. Ядро требует полного контроля над потоком выполнения.

2. Скрытое управление памятью (RAII)

Линус считает, что компилятор не должен делать ничего "за спиной" программиста.

Проблема: Конструкторы, деструкторы и неявные аллокации.

Аргумент: В ядре управление памятью должно быть ручным и прозрачным. Зависимость от магии компилятора снижает производительность и стабильность.

3. "Жирная" объектная модель

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

Цитата: "Ограничение проекта языком C означает, что люди не смогут его испортить... идиотской чушью 'объектной модели'".

Как выглядит ООП в стиле Linux (на чистом C):

Вместо классов - структуры и указатели на функции. Это дает полиморфизм без оверхеда C++.

typedef struct {

int value;

// V-table на минималках: указатель на функцию

void (*increment)(struct Person *self);

} Person;

void increment_person(Person *self) {

self->value++;

}

int main() {

Person *p = (Person*)malloc(sizeof(Person));

p->value = 5;

p->increment = increment_person; // Привязка метода

p->increment(p); // Вызов: 6

free(p);

}

4. Проблема зависимостей (STL/Boost)

То, что стабильно для приложения в GNOME, недостаточно стабильно для ядра. Внедрение STL или Boost - это риск security-проблем (вспомним бэкдор в xz/liblzma) и раздувание бинарников.

А как же Rust?

Интересно, что к Rust отношение другое. Линус допускает Rust, потому что он (в отличие от C++) решает проблемы безопасности памяти, а не просто добавляет синтаксический сахар. C - прост, но позволяет выстрелить себе в ногу. Rust - строг. C++ - слишком сложен и неявен для ядра.

Отказ от C++ - это выбор между эргономикой разработчика и стабильностью системы. Для User-space приложений C++ прекрасен. Но для ядра, от которого зависит работа миллиардов устройств (от тостеров до спутников), консерватизм C - единственно верный путь.

Читать статью полностью: https://habr.com/ru/companies/otus/articles/902724/

Холивар в комментах объявляется открытым: Согласны с Линусом, что C++ переусложнен для системного уровня, или это просто "синдром утенка" у старой школы?


Источник: max.ru

Комментарии: