ncpp: Как создать самодостаточную экосистему на С++98 в 2026 году, которая запустится даже на железе со свалки

В сфере искусственного интеллекта произошло заметное событие. Vlad441 8 минут назад ncpp: Как создать самодостаточную экосистему на С++98 в 2026 году, которая запустится даже на железе со свалки Средний 6 мин 100 C++ * Программирование * Ненормальное программирование * Старое железо Системное программирование * Кейс Современный С++ стал значительно удобнее по сравнению с прошлыми стандартами. STL и стандартная библиотека существенно облегчают жизнь программиста. С каждой новой версией стандарта добавляют что-то новое, что помогает упростить (или усложнить) очередной аспект разработки.

Однако со временем при разработке на С++ начинают появляться вопросики:Везде ли скомпилируется ли моя программа? Поддерживается ли текущая версия компилятора для моей ОС? Поддерживается ли текущий стандарт в моей версии компилятора?

Технические детали

Везде ли запуститься моя программа? Какие зависимости тянет моя программа? Есть ли эти зависимости в минимальной комплектации моей ОС?

Или может проще все статически намертво слинковать? На сколько эффективны стандартные реализации? На сколько эффективно они линкуются?

Какой будет итоговый размер исполняемого файла? Обилие этих вопросов побудило меня на вопрос А возможно ли это решить? , и я попробовал написать свою реализацию системной библиотеки, которая призвана минимизировать количество таких проблем.

Отраслевые последствия

Выбор стандарта и окруженияКак же можно запуститься на максимально возможном количестве конфигураций металлолома, сохраняя минимальный комфорт который дает C++? Самый ранний из доступных стандартов - C++98, под него больше всего поддерживаемых компиляторов (а следовательно и архитектур и ОС для них) было выпущено. От каких минимальных версий ОС стоит отталкиваться?

В ходе изучения доступных системных вызовов на разных версиях ОС, системных вызовов из Win XP в большинстве своем достаточно для комфортной работы и на Win 10+, а некоторые улучшения в новых версиях можно уже добавить в ходе Progressive Enhancement. Что на счет Linux, версия ядра 2. 6 уже содержит большинство вызовов, которые используются сегодня, например epoll(), pthread_* и прочие.

По компиляторам я пришел к выводу, что более-менее возможно поддерживать компиляторы начиная с gcc 3. 4 (с натяжкой при Graceful Degradation), а более полноценно поддерживать начиная с gcc ~4. 9, собирая тесты на этой версии, а далее уже следовать Progressive Enhancement.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.