LINUX.ORG.RU

Герб Саттер — отчёт о встрече по стандартам ISO C++ в июне 2026 года

 ,


2

4

https://herbsutter.com/2026/06/13/brno-trip-report.

Несколько минут назад (прим.: 13 июня 2026 г.) комитет ISO по C++ завершил первое заседание по C++29 в прекрасном городе Брно, Чехия (в гибридном формате с онлайн-участием через Zoom).

Организатором этой встречи выступил Университет имени Менделя в Брно. Благодарим всех, кто принимал участие в её проведении, и в особенности Хану Дусикову, которая возглавила работу по подготовке мероприятия! Наши хозяева обеспечили нам высококачественные условия для проведения шестидневной встречи с понедельника по субботу.

В мероприятии приняли участие около 200 человек, из которых примерно 55% присутствовали на месте, а 45% — онлайн; они официально представляли 28 стран. На каждой встрече у нас регулярно появляются новые гости, которые никогда раньше не участвовали в мероприятии, и на этот раз, помимо новых участников, являющихся официальными представителями национальных организаций, было 25 новых гостей, в основном присутствовавших на месте. Ещё раз приветствуем всех!

В настоящее время в составе комитета действуют 22 подгруппы, 11 из которых в течение недели проводили заседания в рамках 6 параллельных сессий. Некоторые группы работали всю неделю, а другие — несколько дней или часть дня, в зависимости от объёма работы. Краткое изложение процедур ISO можно найти здесь.

Принято для C++29: Изменения и новые возможности ядра языка

Эти ссылки ведут на самые последние общедоступные версии каждой статьи. Если статья была доработана на заседании перед утверждением, ссылка отслеживает изменения и автоматически найдёт обновлённую версию, как только она будет загружена на общедоступный сайт. Некоторые из принятых нововведений в языке и библиотеках уже сегодня поддерживаются в основных реализациях C++. «Принято для C++29» не означает, что «придётся ждать до 2029 года или позже, чтобы увидеть их поддержку в реальных компиляторах и стандартных библиотеках». Помимо устранения ряда проблем, основная рабочая группа одобрила 19 документов, в том числе следующие:

  • P3596R3 «Неопределённое поведение и приложения IFNDR» (авторы: Joshua Berne, Timur Doumler, Jens Maurer и Shafik Yaghmour). Данная статья дополняет стандарт C++ двумя приложениями, в которых подробно каталогизированы и задокументированы все случаи неопределённого поведения (UB) в C++, включая случаи, помеченные как «некорректная форма, диагностика не требуется» (IFNDR). Данный каталог предназначен для содействия смягчению или устранению случаев UB, в том числе с помощью профилей. Это была, простите за мой французский, целая «[метрическая] тонна» работы, проделанной на протяжении нескольких лет. Спасибо Shafik, Joshua, Timur, Jens и всем, кто помог им составить этот подробный каталог, благодаря чему теперь мы сможем систематически заняться этими случаями неопределённости (UB)! Следующим шагом станет рассмотрение каждого случая в отдельности, которое начнётся в следующем месяце с целью систематического решения этих проблем к C++29, возможно, уже в течение следующего года (подробнее об этом ниже). Здесь, в C++, мы смотрим в глаза реальности без страха и пристрастий. На случай, если это нужно повторить: «Да, Вирджиния, существует динамичный, живой и современный язык программирования под названием C++». (Только, в отличие от оригинала, эта версия — правда для взрослых).

  • P3097R3 «Контракты в C++: виртуальные функции» (авторы: Timur Doumler, Joshua Berne и Gašper Ažman). Цитата из статьи:

    «Утверждения переопределяющей функции не зависят от утверждений в переопределяемой функции. При вызове виртуальной функции оцениваются утверждения о предварительных и конечных условиях как статически выбранной функции, так и конечной переопределяющей функции. Данный подход развивает ранее предложенные решения, поддерживая более широкий спектр сценариев использования, встречающихся в существующем коде, более естественно интегрируясь с семантикой оценки контрактов и обработкой нарушений контрактов в C++26, а также лучше подходя для языка C++, чем более ограничительные модели в таких языках, как Eiffel и D».

    Добавление этой функции устраняет одну из основных претензий к контрактам в C++26, а именно то, что первоначальная версия контрактов не поддерживала виртуальные функции. Теперь, менее чем через три месяца после технического завершения работы над C++26, в проекте стандарта C++29 контракты уже поддерживают виртуальные функции. Это свидетельствует о том, что комитет серьёзно настроен на развитие контрактов C++26 в рамках C++29. Спасибо, Timur, Joshua and Gašper!

  • P3668R4 «Операции инкремента и декремента в постфиксной нотации по умолчанию» (авторы: Matthew Taylor и Alex). В данной статье добавляется поддержка =default для операторов инкремента и декремента в постфиксной нотации, что позволяет использовать каноническое определение, отсылающее к префиксным версиям, без необходимости вручную писать шаблонный код (и, возможно, допускать ошибки). Спасибо, Matthew и Alex! Например, приведённый в статье пример теперь допустим в проекте C++29:

class foo{
    int member;
public:
    constexpr foo& operator++(){
        ++member;
        return *this;
    }
    constexpr foo operator++(int) = default;
};
struct A { int a; };

struct B : A { int b; };

B{{1}, 2}         // уже допустимо в C++17
B{1, 2}           // уже допустимо в C++17

B{.a=1, .b=2}     // теперь допустимо в C++29
B{{.a=1}, .b=2}   // теперь допустимо в C++29
B{.a{1}, .b{2}}   // теперь допустимо в C++29

B{.b=2, .a=1}     // остаётся недопустимым

Кроме того, мы добавили ещё целый ряд языковых расширений и улучшений.

Принято для C++29: Изменения и новые возможности стандартной библиотеки

Помимо устранения ряда проблем, в стандартную библиотеку были включены 18 статей, в том числе следующие:

  • P3091 «Улучшенные операции поиска для map, unordered_map и flat_map» (автор: Pablo Halpern). Этот документ добавляет в C++29 поддержку вызова .lookup(key) в стиле Python для map, unordered_map и flat_map. Эта функция, возвращающая опциональный параметр, открывает возможности, недоступные сегодня с помощью оператора [], который всегда вставляет элемент, если его нет, и find, который находит только те элементы, которые присутствуют. Спасибо, Pablo! Вот пример из статьи:
constexpr double inf = std::numeric_limits<double>::infinity();

double largest = -inf;

for (int i = 1; i <= 100; ++i) {
  largest = std::max(largest, theMap.lookup(i).value_or(-inf));
}
  • P3125R6 «Маркировка указателей constexpr» (автор: Hana Dusíková, известная как «королева constexpr»). Представленный в этой статье тип указателя с тегом pointer_tag_pair<Pointer, BitsRequested = /* доступные младшие биты */, Tag = unsigned> обеспечивает переносимую поддержку хранения информации в младших битах указателей. Это библиотека низкого уровня, полезная для решения многих задач, включая обеспечение безопасности памяти и усиление защиты. Спасибо, Hana!
  • P3248 «Сделать [u]intptr_t обязательными» (автор: Gonzalo Brito Gadeschi). Формально в C и C++ до сих пор типы intptr_t и uintptr_t были «необязательными», поэтому реализация на C++ могла не поддерживать их. Поскольку они полезны для низкоуровневого кода и уже широко поддерживаются, теперь стандарт C++ будет требовать их наличия. Спасибо, Gonzalo!
    Мы также добавили ряд других расширений и улучшений библиотеки.
Другие достижения, в частности в области обеспечения безопасности работы с памятью

На этой неделе мы также добились других важных успехов в работе над функциями, которые пока не готовы к включению в проект стандарта. Приведённый ниже список не является исчерпывающим, но я хотел бы особо выделить прогресс, достигнутый в нескольких направлениях, связанных с безопасностью памяти:

  • Систематическое решение проблемы неопределённого поведения (UB) в C++ для стандарта C++29. Подгруппа по развитию языка (EWG) также одобрила выделение значительного времени этим летом и осенью на построчное рассмотрение в режиме телеконференции документа P3100 «Концептуальная основа для систематического решения проблемы неопределённого поведения в стандарте C++» (авторы: Timur Doumler and Joshua Berne), с целью включения его в стандарт C++29. Отличное краткое изложение можно найти в аннотации к документу.
  • Спецификация профилей для C++29. Подгруппа по безопасности и защите (SG23) приняла решение разработать спецификацию профилей, которая позволит использовать правила статического и иного анализа, ограничивающие набор функций C++, с целью обеспечения того, чтобы в коде не использовались нежелательные (например, небезопасные с точки зрения памяти) операции, и тем самым усилить безопасность кода C++ определёнными способами. Эта спецификация будет включена в C++29, если она будет готова вовремя, как ожидается; в противном случае она может быть опубликована в виде технического документа одновременно с C++29.
  • Профиль инициализации. Группа SG23 также рассмотрела текущий проект документа P4222 «Профиль инициализации» (автор: Bjarne Stroustrup), и мы рассчитываем добиться дальнейшего прогресса в этой работе в течение этого года, в том числе с учётом опыта реализации по крайней мере в одной крупной кодовой базе компилятора.

Как я уже упоминал в своих предыдущих отчетах о поездках, среди других документов по профилям, над которыми я ранее работал, можно назвать P3984 «Профиль безопасности типов» (автор: Bjarne Stroustrup) и P3589R2 «Профили C++: инфраструктура» (автор: Gabriel Dos Reis), а также ряд других дополняющих их документов с предложениями по профилям.

Сказать, что это были бы чрезвычайно важные и исторические достижения — значит сильно преуменьшить их значение:

  • предоставляется способ систематически решать проблемы, связанные с неопределённым поведением (UB) в C++, и
  • предоставляется способ гарантировать, что программа на C++ обладает определёнными свойствами, например, отсутствие ошибок, связанных с безопасностью работы с памятью.

Мы ещё не достигли этой цели, но обе задачи теперь явно выходят за рамки простого желания; это серьёзные рабочие задачи, по которым комитет намерен добиться значительного прогресса в ближайшем будущем. Я буду продолжать освещать эти усилия в будущих отчётах о поездках по мере продвижения работы.

Напоминание для тех, кто по-прежнему скептически относится к тому, что реализация UB на C++ когда-нибудь станет возможной: помните, что мы уже этим занимаемся. Не живите прошлым… «Уже не 2021 год». BeCPP, YouTube.

  • Код constexpr C++, который в настоящее время охватывает практически весь язык C++ и стандартную библиотеку, уже гарантированно не вызывает неопределённого поведения при выполнении на этапе компиляции.
  • В C++26 были устранены ещё два основных источника неопределённого поведения (UB): использование неинициализированных переменных стека больше не приводит к UB, а в упрочнённой стандартной библиотеке C++ добавлена защита от выхода за пределы для десятков наиболее распространённых операций с границами (эта функция уже широко внедрена для упрочнения платформ Apple и Google; подробнее об этом см. в моём предыдущем отчёте о поездке).
В заключение

Еще раз благодарим около 200 экспертов, которые приняли участие в заседании на этой неделе как очно, так и в режиме онлайн, а также всех тех, кто участвует в работе по стандартизации через свои национальные органы!

Но мы не собираемся сбавлять обороты… Мы продолжим проводить заседания подгрупп в Zoom, а наше следующее полное заседание состоится в ноябре в Армасан-дус-Бузиус, недалеко от Рио-де-Жанейро (Бразилия), где мы продолжим работу над добавлением новых возможностей в C++29. Надеюсь увидеть многих из вас там.

Спасибо всем, кто читает это сообщение, за ваш интерес и поддержку C++ и его стандартизации.

★★★★★

B{.a=1, .b=2} // теперь допустимо в C++29
B{.b=2, .a=1} // остаётся недопустимым

Форкома c девочкой и «буду проституткой», только теперь на книжке надпись «Драфт C++29»...

GAMer ★★★★★
()

Эта функция, возвращающая опциональный параметр, открывает возможности, недоступные сегодня с помощью оператора [], который всегда вставляет элемент, если его нет,

Обожаю C++ за вот такие незаметные способы отстрелить себе член ^__^

yorshka
()
Ответ на: комментарий от unDEFER

А может ты не прав. VariCAD на С++. И не дорого так для linux платформы.

saufesma
()
Ответ на: комментарий от yorshka

незаметные способы

Но это самый заметный.

отстрелить себе член

Объяви мапу const и тебе член отстрелит компилятор ещё на этапе сборки.

r--r--r--
()
Ответ на: комментарий от r--r--r--

незаметные способы

Но это самый заметный.

Да нет, средненько. Такие выкрутасы, например, не позволяют совать различные контейнеры в шаблонный код, потому как у них разное поведение для одних и тех же операторов.

yorshka
()
Ответ на: комментарий от yorshka

не позволяют совать различные контейнеры в шаблонный код

Да ты и не в шаблонный разные совать не можешь. Для контейнеров никто никогда не обещал совместимости по интерфейсам с момента создания. У них методы и операторы чисто совпадают по именам.

r--r--r--
()
Ответ на: комментарий от r--r--r--

Для контейнеров никто никогда не обещал совместимости по интерфейсам с момента создания. У них методы и операторы чисто совпадают по именам.

Это всё понятно. Не понятно только нахера так делать.

yorshka
()
Ответ на: комментарий от r--r--r--

Форкома

ну гайдзин ёнкома )

Ёнкома, также известная как 4-кома

Хотя в той картинке(пересчитал, да!)всё-таки 5 кадров.

GAMer ★★★★★
()
Ответ на: комментарий от unDEFER

Когда людям делать нечего, они стандарт C++ разрабатывают…

Вы даже представить себе не можете, как вы правы. Имею удовольствие наблюдать за этой клоунадой последние 15 лет - сотрудники нашей группы являются активными членами этого, так сказать, комитета. Никто никогда не видел их на работе. Никто никогда не видел от них пользы. Никто никогда не видел от них ни строчки кода ни на каком языке, включая С++. Они не участвуют в разработках группы. Им некогда. Они в поездках. Они разрабатывают никому кроме них не нужный очередной стандарт С++. Они даже объяснить не могут, зачем этим всем они занимаются. Не успели отсидеть в Брно, теперь всей командой переехали в Фолькстоун. Потом ещё куда-нибудь. Можно порадоваться за людей, жизнь удалась, имеют фан, что ещё нужно?

VIT ★★
()

Базара нет. Всречают по стандартам.

Всречают по стандартам, а провожают по?.. коду?

BruteForce ★★★★
()
Ответ на: комментарий от VIT

Именно - конфы, конфы и ещё конфы богам конфы. Как в науке, только спп не наука, а очень даже прикладная вещь. И весь этот чудо юдо стандарт имно максимально оторван от реальных потребностей. Вернее может он и подходит всяким гуглам и фф, но для реальной жизни он безнадёжно отстал.

vtVitus ★★★★★
()
Ответ на: комментарий от vtVitus

Даже гуглам и фф он нахрен не нужен; для внутреннего потребления им дешевле создать свой подконтрольный язык, да ещё и потому что люди в комитете разработкой не занимаются, не барское это дело, код писать. Важную роль играют представители компиляторов, особенно Nvidia, Intel, ARM, и LLVM. Они кровно заинтересованы в том, чтобы «высеXы» этих стандартизаторов можно было сравнительно безболезненно воплотить в жизнь, а иначе труба и сам будешь виноват.

VIT ★★
()
Ответ на: комментарий от r--r--r--

Вставка элемента квадратными скобками это мегафича! Я не понимаю как люди пишут на петонах без этого. Постоянно надо приседать с портянкой if’ов!

Reset ★★★★★
()

автор: Bjarne Stroustrup

На помойку.

BruteForce ★★★★
()
Ответ на: комментарий от Reset

Вставка элемента квадратными скобками это мегафича!

Это просто от бедности выразительных средств языка.

unC0Rr ★★★★★
()
Ответ на: комментарий от ya-betmen

Они что, его каждый год разрабатывают?

Нет, разрабатывают круглосуточно. А встречаются, как минимум, ежегодно. :)

dataman ★★★★★
() автор топика

Утверждения переопределяющей функции не зависят от утверждений в переопределяемой функции. При вызове виртуальной функции оцениваются утверждения о предварительных и конечных условиях как статически выбранной функции, так и конечной переопределяющей функции.

ох уж эти формулировочки

Bad_ptr ★★★★★
()

Напоминание для тех, кто по-прежнему скептически относится к тому, что реализация UB на C++ когда-нибудь станет возможной: помните,

она возможна с 1985 года.

water_closed
()
Ответ на: комментарий от VIT

Имею удовольствие наблюдать за этой клоунадой последние 15 лет - сотрудники нашей группы являются активными членами этого, так сказать, комитета. Никто никогда не видел их на работе.

А эта группа она чем-то в коммерческой организации занимается? Или это какой-то академический институт или ВУЗ?

eao197 ★★★★★
()
Ответ на: комментарий от VIT

Пусть развлекаются как хотят. Зато есть стандарт и несколько реализаций от разных команд. Можно быть уверенным, что я смогу и завтра писать на этом языке, и разработчики не выбросят его как надоевшую игрушку.

hobbit ★★★★★
()
Ответ на: комментарий от VIT

Это не так работает. Это вопрос престижа фирмы. Способ завлечь новых людей на работу к вам :) От нас тоже Саттер ездит в фирменной футболке по всем митапам и рабочим группа. Кто-нибудь видел его код за последние лет 20? Я не видел :)

Reset ★★★★★
()
Ответ на: комментарий от unC0Rr

Так, пятница сама себя не начнёт, пора начинать пятницу.

Вставка элемента квадратными скобками это мегафича!

Это просто от бедности выразительных средств языка.

А в богатых выразительными средствами языка это делают круглыми скобочками?

r--r--r--
()
Ответ на: комментарий от hobbit

Пусть развлекаются как хотят.

Если бы результаты их развлечений затем не влияли на других людей. А то возьмет кто-то, примет в стандарт std::aligned_storage. Люди начнут пользоваться, набьют шишек. А потом хоба! И нужно выпиливать из кода. Что особенно неприятно, если код написан давно, работает себе и особо нет ресурсов на то, чтобы есть перелопачивать.

Или, скажем, введут в С++17 std::launder без которого пару десятилетий обходились. А потом додумаются, что одного std::launder недостаточно. Что нужно еще и std::start_lifetime_as.

Или примут в C++26 кастрированные контракты (речь про элементы Design By Contract, что уже давным-давно есть в Eiffel и D). Типа живите пока с убожеством, пока до ума не доведем. А в потом в C++29 расширяют поддержку этих контрактов, но так, что прям ой (eao197.blogspot.com).

В общем, с одной стороны, большое спасибо комитету, что язык все же развивается и обрастает полезными фичами (концепты и operator<=> чего стоят). Но и вопросов к работе комитета так же накапливается множество.

eao197 ★★★★★
()
Ответ на: комментарий от Reset

От нас тоже Саттер ездит в фирменной футболке по всем митапам и рабочим группа. Кто-нибудь видел его код за последние лет 20? Я не видел :)

Так он же вроде свой cppfront в открытую пилит. Вполне можно глянуть на код Саттера :)

eao197 ★★★★★
()
Ответ на: комментарий от hobbit

Ну конечно, за наш счёт то почему не поразвлекаться? У организации вообще-то говоря и своя работа есть, её кто выполнять будет, пока эти разъездяи развлекаются?

VIT ★★
()
Ответ на: комментарий от VIT

Государственная организация

И вопросов о том, чем же эти ребята на работе занимаются не возникает?

eao197 ★★★★★
()
Ответ на: комментарий от Reset

Мы не нуждаемся в престиже. У нас есть mission, назначенная Конгрессом. В эту миссию разработка стандарта С++ вообще никаким боком. А кто работу то выполнять будет, пока эти в Брнах пиво пьют?

VIT ★★
()
Последнее исправление: VIT (всего исправлений: 1)
Ответ на: комментарий от VIT

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Вообще нет шансов. Всё как всегда. Один такой недавно ушёл на повышение, всё польза. На его место взяли человека, который работает во благо. А с остальными ничего не сделаешь, у них каждая такая поездка - пять публикаций и международный престиж.

VIT ★★
()
Ответ на: комментарий от VIT

В начале 2000-х читал про особенности процесса стандартизации (может быть даже у Страуструпа). Там говорилось про подобных персонажей, которые хз каким боком к C++, но имеют время и ресурсы участвовать в заседаниях.

Надеялся, что с течением времени процент таких людей в комитете снизился.

eao197 ★★★★★
()
Ответ на: комментарий от yorshka

По мне так лучше бы была возможность перегружать оператор в зависимости от контекста (lvalue/rvalue). И тогда lvalue-[] бы создавал элемент, а rvalue-[] не создавал бы. Но язык такое не позволяет. Впрочем, можно сделать костылями, возвращая из [] не сам элемент, а обёртку над ним, которая создаёт элемент только в момент записи в неё.

Впрочем, это всё рассуждения со стороны, использовать современный С++ у меня всё меньше и меньше желания. В том виде как он был в начале 2000-х - нравилось больше.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от eao197

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

VIT ★★
()
Ответ на: комментарий от VIT

Кстати, это наблюдается только в комитете стандарта С++. В других комитетах такого явного отрыва членов от реалий я не видел. Люди, которые занимаются Фортраном, mpi forum, OpenMP, Khronos group, имеют вполне себе разумные профессиональные достижения. И только Си++ проела ржа профессиональных разработчиков стандарта.

VIT ★★
()

На каждой встрече у нас регулярно появляются новые гости,

У кого «у нас»? У датамана?

lolkasosaka
()
Ответ на: комментарий от vtVitus

только спп не наука

А может плохо, что не наука? Может сначала надо подумать, а потом языки разрабатывать?

lolkasosaka
()
Ответ на: комментарий от VIT

Но кто же в госконторе думает о пользе?

Главное чтоб зарплату и бонусы платили. «Польза» это понятие субъективное :)

Reset ★★★★★
()
Ответ на: комментарий от Reset

Нет, это не главное. Если для вас главное зарплата и бонусы, то в нашей группе вам не место.

VIT ★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.