29 марта 2026 года комитет ISO C++ завершил техническую работу над стандартом C++26. Херб Саттер — председатель комитета стандартизации с 2002 по 2025 год и один из самых влиятельных людей в мире C++ — называет этот релиз самым значительным со времён C++11. Не «ещё одно инкрементальное обновление», а фундаментальный сдвиг в том, как язык работает с самим собой, с безопасностью и с параллелизмом. Давайте разберёмся, что именно изменилось и почему это касается каждого, кто пишет на C++.
«Великолепная четвёрка» C++26
Саттер выделяет четыре ключевых фичи, ради которых стоит обновляться. Каждая из них — не просто синтаксический сахар, а изменение парадигмы в своей области.
Рефлексия: C++ наконец-то может описывать сам себя
Саттер не стесняется в выражениях и называет рефлексию самым большим апгрейдом для разработки на C++ со времён изобретения шаблонов. И я, честно говоря, склонен согласиться.
Что это такое в двух словах? Рефлексия позволяет программе на этапе компиляции анализировать собственные типы, функции, поля — и генерировать новый код на основе этого анализа. До C++26 метапрограммирование на C++ означало шаблонную магию: рекурсивные шаблоны, SFINAE, constexpr if, концепты — всё это работало, но выглядело как заклинания на языке, который не предназначен для того, что вы пытаетесь сделать. Потому что, по сути, так и было.
С рефлексией C++ впервые получает легитимный механизм интроспекции. Представьте: вы определяете структуру с десятью полями и хотите автоматически сгенерировать для неё сериализацию в JSON, функцию сравнения, хэш-функцию, pretty-print для отладки. Раньше это требовало либо макросов (хрупких и нечитаемых), либо внешних кодогенераторов (дополнительный шаг сборки), либо ручного написания одного и того же бойлерплейта для каждого типа. Теперь компилятор сам знает, какие поля есть у структуры, какие у них типы, и может сгенерировать весь этот код автоматически — в compile-time, с нулевым оверхедом в рантайме.
В своём кейноуте на CppCon 2025 Саттер сформулировал это так: C++ впервые может описывать самого себя и генерировать ещё больше себя. Звучит как рекурсия, но на практике это означает, что целые категории библиотек — от ORM до сериализаторов и тестовых фреймворков — можно будет писать принципиально иначе.
Безопасность памяти: просто перекомпилируйте
Вот это, на мой взгляд, самая практически важная часть. C++26 делает ваш существующий код безопаснее — просто перекомпиляцией. Без единого изменения в исходниках.
Два механизма:
🛡️ Устранение UB при чтении неинициализированных переменных. В предыдущих стандартах чтение неинициализированной локальной переменной было неопределённым поведением (undefined behavior, UB). Компилятор мог делать что угодно — от подстановки мусорного значения до оптимизации, которая удаляла целые ветки кода. Это был источник бесконечных уязвимостей. В C++26 этот класс UB просто исчезает.
🛡️ «Укреплённая» стандартная библиотека (hardened standard library). Это проверки границ для десятков самых используемых операций на vector, span, string, string_view и других контейнерах. Технически — это bounds-checking, который встраивается в стандартную библиотеку по умолчанию.
И тут начинается самое интересное — реальные цифры из продакшена. Это не теоретическая разработка: Apple и Google уже развернули hardened-версию стандартной библиотеки на сотнях миллионов строк кода. Статья в ACM Queue от ноября 2025 года даёт конкретику: в Google только пять сервисов полностью отказались от hardening из-за проблем с производительностью или надёжностью. API для обхода проверок был использован всего в семи местах — и все семь были хирургическими изменениями от команды безопасности. Средний оверхед по производительности — 0.3%, то есть меньше процента.
Результат? Более тысячи найденных багов, прогноз на предотвращение 1000–2000 багов ежегодно, и снижение частоты segfault-ов по всему продакшен-флоту Google на 30%.
Тридцать процентов. Просто от перекомпиляции с обновлённой стандартной библиотекой. Это не маркетинг — это реальные данные из инфраструктуры, через которую проходит значительная часть мирового интернет-трафика.
Контракты: pre, post, contract_assert
Контракты — это формализованный механизм для описания предусловий (preconditions) и постусловий (postconditions) функций, а также языковой аналог assert, который бесконечно лучше Сишного макроса assert().
Как это выглядит на практике? Вы пишете функцию и прямо в объявлении указываете: «этот аргумент должен быть положительным» (precondition), «возвращаемое значение гарантированно не null» (postcondition). Компилятор проверяет эти контракты при вызове и/или при возврате.
Тема оказалась не без споров. Саттер честно признаёт, что часть уважаемых экспертов комитета имеет устойчивые технические возражения. Голосование за включение контрактов в рабочий черновик в феврале 2025-го: 100 за, 14 против, 12 воздержавшихся. Финальное голосование за отправку C++26 на утверждение: 114 за, 12 против, 3 воздержавшихся. Обратите внимание — число воздержавшихся упало с 12 до 3. Практически все эксперты определились с позицией. Большинство — за.
std::execution: единая модель асинхронности
std::execution (известная также как Sender/Receiver) — это унифицированный фреймворк для выражения и управления конкурентностью и параллелизмом в C++. По сути, это «async-модель C++», стандартизированная на уровне языка.
Важное свойство — std::execution поощряет структурированную конкурентность (structured concurrency), при которой время жизни асинхронных операций строго вложено. Это делает data races конструктивно невозможными — не через проверки в рантайме, а через архитектуру кода.
Саттер, впрочем, предупреждает: фича мощная (его компания уже использует её в продакшене), но порог входа высокий. Документация пока слабая, некоторых вспомогательных библиотек не хватает. Совет от Саттера: ожидайте отличных результатов, но будьте готовы потратить время на обучение — желательно с кем-то, кто уже разобрался.
Почему C++26 будут внедрять быстро
Саттер приводит два аргумента, и оба убедительные.
📈 Спрос. C++11 был последним «большим» релизом, который все C++-разработчики использовали ежедневно (auto, range-for, лямбды, умные указатели, move-семантика). С тех пор стандарты C++14/17/20/23 тоже содержали крупные фичи — parallel STL, концепты, корутины, модули — но ни одна из них не затронула каждого разработчика так, как это сделают рефлексия и safety hardening. Даже если ваша компания до сих пор не перешла на C++20, с C++26 мотивация будет другого порядка.
⚡ Компиляторы готовы. На протяжении всей разработки C++26 и GCC, и Clang уже имплементировали примерно две трети фич стандарта. На момент публикации у GCC рефлексия и контракты уже влиты в trunk и ждут релиза. Это радикально отличается от ситуации с C++20, когда на полную поддержку модулей компиляторам потребовались годы.
А что дальше? C++29 и безопасность
Работа не останавливается. Комитет уже принял расписание C++29 (очередной трёхлетний цикл). Главный фокус — ещё больше безопасности памяти.
На мартовской встрече в Лондоне безопасности были посвящены: регулярные сессии подгрупп, вечерняя сессия в среду (пришло большинство комитета), и отдельная выделенная сессия в пятницу на 90 экспертов. Обсуждались Profiles Бьярне Страуструпа — механизм подмножеств языка, ограничивающих опасные конструкции.
Особенно интересен доклад Оливера Ханта из Apple (P4158R0): опыт WebKit, где более 4 миллионов строк C++-кода были усилены с помощью подхода «подмножество-надмножество» (subset-of-superset), аналогичного Profiles. Результат: закрыты целые классы уязвимостей, текущие политики предотвратили бы большинство исторических эксплойтов.
Саттер подводит итог ёмко: «это уже не дикий запад UB нашего дедушкиного C++». Язык движется к безопасности по умолчанию, сохраняя верность своему ключевому принципу — zero-overhead. Не используешь проверку? Не платишь за неё. Используешь — платишь доли процента.
Мой взгляд
C++26 — это, пожалуй, первый стандарт за последние 15 лет, который заставит даже консервативные проекты всерьёз задуматься об обновлении. Рефлексия — это фича, которую каждый C++-разработчик будет использовать, осознанно или через библиотеки. Hardened стандартная библиотека — это тот редкий случай, когда «просто перекомпилируй» реально делает код безопаснее, с цифрами из продакшена Google и Apple в качестве доказательства.
Контракты вызывают споры, и это нормально — в комитете из сотен экспертов единогласие по серьёзным фичам было бы подозрительным. Но 114 против 12 — это очень сильный консенсус, и я думаю, что практика покажет правильность решения.
Что касается std::execution — тут я согласен с Саттером в его осторожности. Фича нужная, но без нормальной документации и экосистемы хелперов массовое внедрение будет медленным. Это как корутины в C++20: технически мощно, практически — пока непросто.
А самый интересный тренд — это курс на безопасность в C++29. Годами критики говорили, что C++ невозможно сделать memory-safe без потери его сути. C++26 с hardened-библиотекой и C++29 с Profiles — это ответ комитета: можно, и при 0.3% оверхеда. Rust-сообщество, вероятно, не согласится, что этого достаточно. Но для миллиардов строк существующего C++-кода, которые никто не перепишет на Rust, это огромный шаг вперёд.
Следующие встречи комитета — в Брно (Чехия) в июне и Бузиос (Рио-де-Жанейро, Бразилия) в ноябре. Работа над C++29 начинается уже там.
Источники
🔗 Оригинальный трип-репорт Херба Саттера: https://herbsutter.com/2026/03/29/c26-is-done-trip-report-march-2026-iso-c-standards-meeting-london-croydon-uk/
🔗 Изложение на Telegraph: https://telegra.ph/C26-Kak-yazyk-vzyal-kurs-na-bezopasnost-i-uznal-chto-o-sebe-dumaet-03-29
🔗 Кейноут Саттера на CppCon 2025 о рефлексии: https://www.youtube.com/watch?v=7z9NNrRDHQU
🔗 Доклад Саттера на CppCon 2025 о контрактах: https://herbsutter.com/2025/10/01/my-other-cppcon-talk-video-is-now-available-the-joy-of-c26-contracts-and-some-myth-conceptions/
🔗 Статья ACM Queue о hardened стандартной библиотеке в Google и Apple: https://queue.acm.org/detail.cfm?id=3773097
🔗 Трип-репорт (июнь 2025, рефлексия): https://herbsutter.com/2025/06/21/trip-report-june-2025-iso-c-standards-meeting-sofia-bulgaria/
🔗 Трип-репорт (февраль 2025, hardened library): https://herbsutter.com/2025/02/17/trip-report-february-2025-iso-c-standards-meeting-hagenberg-austria/
🔗 Трип-репорт (июль 2024, std::execution): https://herbsutter.com/2024/07/02/trip-report-summer-iso-c-standards-meeting-st-louis-mo-usa/
🔗 P3984R0 — Type safety profile Бьярне Страуструпа: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3984r0.pdf
🔗 P4158R0 — Опыт Apple/WebKit по memory safety: https://isocpp.org/files/papers/P4158R0.pdf
🔗 P3045R7 — Библиотека величин и единиц: https://open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3045r7.html