Линус Торвальдс против C++: Почему ядро Linux остается на C? |
||
|
МЕНЮ Главная страница Поиск Регистрация на сайте Помощь проекту Архив новостей ТЕМЫ Новости ИИ Голосовой помощник Разработка ИИГородские сумасшедшие ИИ в медицине ИИ проекты Искусственные нейросети Искусственный интеллект Слежка за людьми Угроза ИИ Атаки на ИИ Внедрение ИИИИ теория Компьютерные науки Машинное обуч. (Ошибки) Машинное обучение Машинный перевод Нейронные сети начинающим Психология ИИ Реализация ИИ Реализация нейросетей Создание беспилотных авто Трезво про ИИ Философия ИИ Big data Работа разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика
Генетические алгоритмы Капсульные нейросети Основы нейронных сетей Промпты. Генеративные запросы Распознавание лиц Распознавание образов Распознавание речи Творчество ИИ Техническое зрение Чат-боты Авторизация |
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 Комментарии: |
|