В последние годы разработчики и сообщество языка программирования C++ все активнее обсуждали вопросы безопасности памяти и способы избежать распространенных ошибок, таких как использование после освобождения памяти (use-after-free) и другие уязвимости. Одним из самых перспективных направлений казалась попытка применить модель безопасности, вдохновленную языком Rust, в экосистеме C++. Однако недавние заявления со стороны комитета по стандартам C++ сигнализируют, что предложение об интеграции модели безопасности Rust, известной своей строгостью и эффективностью, было отклонено в пользу приоритета развития профилей. Эта тема стала объектом значительного интереса и споров в сообществе разработчиков, и в этой статье мы подробно рассмотрим, почему так произошло, что именно означает решение комитета и как это повлияет на будущее C++. Модель безопасности, используемая в Rust, считается революционной в мире системных языков.
Она опирается на точную систему заимствований (borrow checking), которая не позволяет программе обращаться к памяти после ее освобождения и обеспечивает безопасность за счет проверок времени компиляции. В результате разработчики получают гарантии отсутствия целого класса распространенных ошибок без накладных расходов во время выполнения кода. Это стало мощной стороной Rust, позволившей ему завоевать популярность в системном программировании, где традиционно доминирул C++. Понимая значимость и эффективность подобных механизмов, авторы проекта Safe C++, среди которых наиболее заметным является Шон Бакстер, предложили внедрить элементы модели безопасности Rust в C++. Целью была возможность плавной миграции для разработчиков C++ к более безопасному коду без необходимости осваивать совершенно новый язык.
Проект предусматривал введение строгих правил заимствований, анализа инициализации и других проверок во время компиляции, которые помогли бы предотвратить появление небезопасного кода внутри определенного "безопасного" контекста, при этом существующий "небезопасный" код мог работать без изменений. Однако несмотря на очевидные преимущества, предложение столкнулось с серьезным сопротивлением внутри комитета по развитию стандарта C++. Одна из главных причин касается разногласий относительно дизайн-принципов и философии развития языка. У членов комитета существуют определенные взгляды на то, как должен эволюционировать C++, и эти взгляды явно расходятся с концепцией Safe C++. Например, они стремятся избежать необходимости аннотировать функции как "безопасные" или "чистые" таким образом, чтобы безопасная функция могла вызывать только другие безопасные.
Такой принцип, лежащий в основе модели Rust, оказался непримиримым препятствием для принятия Safe C++. При этом комитет по стандартам решил продолжить работу над концепцией профилей, которые по замыслу должны представлять собой наборы требований и гарантий, которые можно применять для определенных контекстов использования C++. Профили позволяют выбирать желаемый уровень безопасности или производительности, что обеспечивает гибкость и адаптатируемость. Именно эта идея получила приоритет и развитие профилей поддерживается на уровне стандарта. Тем не менее разработчики не обошлись без критики в адрес профилей.
Появились претензии, что профили в текущем виде выглядят скорее как концепция без реальной реализации, а их внедрение в стандарт C++ затягивается. Некоторые эксперты указывают, что профили не обеспечивают той уровня безопасности, который можно было бы ожидать, и опасаются, что подобное решение может не оправдать ожиданий и не решить проблем с безопасностью языка в долгосрочной перспективе. Основатель языка C++ Бьёрн Страуструп поддержал идею профилей как способа обеспечить набор предопределенных гарантий, однако даже он признал, что комитет допустил ошибку, не обеспечив включение этой концепции в стандарт C++ 26. Это свидетельствует о сложном пути развития языка и о том, каким образом разные группы внутри сообщества влияют на принятие решений. Шон Бакстер, в свою очередь, скептически относится к перспективам профилей и считает, что они не смогут эффективно решить вопросы безопасности.
Он приводил множество примеров, иллюстрирующих ограниченность и недостатки этой схемы, и отметил отсутствие борьбы за введение безопасной версии стандартной библиотеки (std2), которая могла бы заменить небезопасные компоненты существующей библиотеки. Отказ от Safe C++ и выбор профилей показывают, что в сообществе C++ до сих пор не существует единого понимания, как добиться безопасного программирования без потерь в совместимости и производительности. Это заставляет многих специалистов задумываться о целесообразности использования C++ для критически важных систем и обращении к альтернативным языкам программирования с более современными и строгими механизмами безопасности. В этом контексте растет интерес к Rust, который уже доказал свою способность обеспечивать безопасность памяти и эффективные средства для системного программирования. Также можно отметить работы Google над проектом Carbon, претендующим на роль преемника C++ с 1.
0 версией, планируемой к выпуску не ранее 2028 года. Carbon намерен предоставлять современный и безопасный язык, способный унаследовать лучшие практики C++ и одновременно расширить возможности за счет новых решений. Возвращаясь к C++, можно предположить, что вопрос безопасности языка будет оставаться в центре внимания и в ближайшие годы. Комитет продолжит эксперименты и разработку стандартов, пытаясь найти баланс между классической философией C++, требованиями к производительности и растущими ожиданиями по безопасности. Возможны дальнейшие предложения по улучшению и изменению профилей, а также другие инициативы, направленные на улучшение проверок и анализа кода.
В то же время разработчикам, которые ценят безопасность и ищут эффективные инструменты для предотвращения ошибок памяти, стоит рассмотреть возможность использования альтернатив или крайне аккуратно подходить к применению C++ в критически важных системах. Языки, подобные Rust, набирают популярность внешних сообществ открытого программного обеспечения и крупных компаний благодаря гарантиям безопасности и стабильности. В целом, отказ от модели безопасности Rust в пользу продолжения работы над профилями отражает глубокие внутренние дебаты вокруг будущего C++ и его роли как системного языка, который должен учитывать баланс между гибкостью, производительностью и безопасностью. Следить за развитием темы и анализировать появляющиеся решения будут важно как для профессиональных разработчиков, так и для компаний, использующих C++ в своих проектах. Отказ от Safe C++ демонстрирует сложность интеграции современных парадигм безопасности в устоявшийся язык с многолетней историей и огромным наследием исходного кода.
Однако это не означает конец работы в направлении улучшения безопасности C++. Инновации и новые подходы обязательно появятся, возможно, и в других формах, отвечающих требованиям и философии сообщества. Пока же основным площадками для экспериментов и внедрения новых моделей безопасности остаются альтернативные языки и экспериментальные проекты. В итоге, разработчики и заказчики программного обеспечения будут выбирать инструменты, которые лучше всего соответствуют их потребностям в надежности, безопасности и поддерживаемости кода. .
