C++26

C++26 или C++2c (латиницей), или Си++26 (кириллицей) — ожидаемая редакция языка программирования C++. Разработка началась сразу же после того, как в феврале 2023 года зафиксировали C++23.

С самого начала стандарт получил рабочее имя «Си++26». Си++0x должен был приблизить устаревающий Си++ к современным языкам, непрерывно разрабатываемым под руководством единоличника. (Си++ разрабатывается комитетом и есть много реализаций — в отличие от, например, Python.) Но стандарт запоздал, и с версии 14 новый язык выпускают не «когда готово», а раз в три года, при этом последний год — только доводка. КОВИД не сместил расписание — к пандемии как раз была готова версия 20, а версию 23 подготовили дистанционно.

Заседания

1. 12…16 июня 2023, Варна (Болгария) — первое после пандемии КОВИДа очное заседание.
2. 6…11 ноября 2023, Каилуа-Кона (Гавайи, США)
3. 18…23 марта 2024, Токио (Япония).
4. 24…29 июня 2024, Сент-Луис (Миссури, США)
5. 18…23 ноября 2024, Вроцлав (Польша)
6. 10…15 февраля 2025, Хагенберг-им-Мюлькрайс (Австрия)
7. Июнь 2025, София (Болгария) — ожидается
8. Ноябрь 2025, Каилуа-Кона (Гавайи, США) — ожидается

Запрещены и удалены

Запрещены в языке

Переменные параметры Си без оксфордской запятой

Запрещён void f(int x...); — старый редкий синтаксис переменных параметров Си на разборе стека через va_list. Остаются добавленный позже Си-совместимый void f(int x, ...);, неявный шаблон Си++20 void f(auto... x);

Синтаксис шаблонов и va_list также можно объединить void f(auto... x...); или void f(auto......);, это также запрещено. Остаётся void f(auto..., ...); Такая функция вполне работоспособна, хоть и мало на что нужна.

Мотивация тройная:

• Шаг к шаблонному синтаксису «сколько угодно параметров int», то есть создающему отдельную функцию для нуля, одного, двух параметров. Этот синтаксис постоянно просят.
• Ошибкоопасность — вместо неявного шаблона Си++20 void g(auto ...args); легко написать функцию из одного шаблонного параметра, за которым следуют переменные void g(auto args...);;
• Бессмысленность — с широкой шаблонной функциональностью единственное место, где ещё нужен разбор стека,— собственно совместимость с Си. А ведь этот синтаксис совсем не Си-совместимый.

Удалены из языка

• Любые операции между enum и дробным; enum и другим enum. Ошибкоопасное наследие Си. Запрещены в Си++20, операция «звездолёт» <=> никогда не разрешалась. Использовать явное преобразование типов. Может помешать совместимости с Си, обходится легко: +C1 + C2.
• Функции больше не могут возвращать ссылку на временный объект. На именованный стековый пока ещё могут, хоть это тоже ошибка и диагностируется компиляторами. Константа is_convertible_v<int, const double&> остаётся true, ведь преобразование int → const double& законно в других местах. По мнению Антона Полухина (Яндекс), такое половинчатое решение связано с неявным преобразованием типа — ревизору не сразу понятно, был ли создан временный объект из именованного. Само понятие временного объекта сложное и подразумевает операции вроде взятия поля, которые никогда не сделают из временного объекта именованный или динамический.
• Некодируемые строковые литералы (например, из-за отсутствия конкретного символа в кодировке исполнения) теперь ошибочны. Многосимвольные литералы 'abc' не могут иметь префикса кодировки, и могут состоять только из символов, укладывающихся в одну минимальную кодовую единицу (байт). Для низкоуровневой оптимизации обработки текста лучше использовать bit_cast.
• Уничтожение объекта недоопределённого типа (class X;) операцией delete, даже без запрета (неофициально запрещён большинством компиляторов). Менеджер памяти знает размер выделенного участка и ему не нужна информация о типе. Но раньше предполагалось, что деструктор ничего не делает, что может снижать взаимозависимость между единицами трансляции в настоящем, но если в будущем тривиальный объект станет управляемым, будет утечка памяти.
• Сравнение массивов. Они сравнивались как указатели, с операцией «звездолёт» (Си++20) запретили. Обходится легко: +a == b (Си), std::to_address(a) == b (Си++), нужно редко.

Диагностика доступа до инициализации

Доступ до инициализации — это известный источник ошибок, и теперь запрещён в очень ограниченном виде — только на стеке. Если действительно неопределённое значение нужно — использовать новый атрибут [[indeterminate]].

union всегда считается инициализированным полностью. На объекты в «куче» диагностика не распространяется.

void h() {
  int d1, d2;

  int e1 = d1;           // теперь ошибка
  int e2 = d1;           // теперь ошибка

  assert(e1 == e2);      // OK
  assert(e1 == d1);      // выполнялось, теперь ошибка
  assert(e2 == d1);      // выполнялось, теперь ошибка

  std::memcpy(&d2, &d1, sizeof(int)); // OK, но у d2 теперь ошибочное значение
  assert(e1 == d2);      // выполнялось, теперь ошибка
  assert(e2 == d2);      // выполнялось, теперь ошибка
}

void f(int);

void g() {
  int x [[indeterminate]], y;
  f(y);     // ошибка
  f(x);     // неопределённое поведение
}

Запрещены в библиотеке

• is_trivial и вообще понятие тривиального типа — из-за обманчивости: с одной стороны, может показаться, что тип тривиален по всем статьям, с другой — столь жёсткое требование часто не нужно. Тривиальный тип — это тип, который тривиально конструируется без параметров и тривиально копируемый, и редко нужны оба требования сразу.
  • Понятие «тривиально копируемый» оставлено, хоть и сложное: возможно копирование хотя бы одним из четырёх способов — конструктором/операцией, копирования/переноса, все доступные способы тривиальны (сводятся к memcpy); также тривиальный (ничего не делающий) деструктор.
• memory_order::consume — специфичная работа компилятора и кэша в атомарных переменных, предназначенная для задачи: один поток заполняет переменную данными, второй их потребляет (отсюда название), и более поздние загрузки этой переменной не могут быть вынесены наперёд. К посторонним переменным никаких требований. В Си++17 был устно запрещён, в Си++20 вернули. На отдельных архитектурах (POWER, GPGPU, старые реализации ARM) все загрузки будут consume, но не все — acquire, и на них, по-видимому, лучше использовать платформо-специфичные «хаки» — а в других платформах компиляторы не проверяли зависимостей и ставили барьер типа acquire (никакой доступ к памяти не может быть вынесен наперёд). Теперь всегда consume == acquire. Свойство volatile в Java также, по сути, acquire. Аннотация [[carries_dependency]] (Си++11) осталась, но больше ничего не делает.

Удалены из библиотеки

• Весь заголовок <codecvt> — нет обработки ошибок. Запрещён в Си++17. Использовать внешние, более управляемые функции.
• allocator<T>::is_always_equal. Ошибкоопасен при наследовании от аллокатора, в котором этот is_always_equal есть. Запрещён в Си++20, для проверки возможностей аллокатора использовать allocator_traits. Использовать в собственных аллокаторах, когда это действительно играет роль.
• string.reserve() без параметров, эквивалентный reserve(0). Со старым API строк (Си++98…17) использовалось как shrink_to_fit, им же и заменено. В Си++20 reserve больше не укорачивает строку, а данную перегрузку запретили.
• strstream (поток, который пишет в буфер памяти) — запрещён давно в Си++98 из-за опасности переполнения буфера. Использовать spanstream (Си++20).
• wstring_convert (преобразование кодировок из многобайтовой в Юникод, заголовок <locale>) — запрещено в Си++17 из-за сложности.
• Атомарный API shared_ptr — запрещён в Си++20, использовать atomic.

Снят запрет

• polymorphic_allocator.destroy — запрещено в Си++20. Пусть это же можно сделать и через allocator_traits, так короче.

Язык

Разные изменения в языке

• Параметром-значением в шаблонах (non-type template parameter) может стать и вызов конструктора. Указано, когда такой вызов возможен, а когда нет.
• Теперь можно навешивать атрибуты и на структурные переменные: auto [a, b [[vendor::attribute]], c] = f();. Предложенное назначение — аннотирование кода для углублённой проверки на безопасность: например, char* в данном месте не требует закрывающего нуля.
• Структурные переменные в условных операторах сами могут быть условием, если для структуры в целом существует надлежащее преобразование в bool: if (auto [ptr, ec] = std::to_chars(p, last, 42)){} (вместе с изменениями в библиотеке).
• union, независимо от внутренних типов, тривиально конструируется-уничтожается — например, чтобы отвести место на неинициализированную память. Такая неинициализированная память, если возможна, то проще, чем буфер постороннего типа alignas(T) char buf[N], и к тому же constexpr. Исключение: если одно из полей инициализировано по умолчанию, конструктор не тривиален, а если это поле ещё и снабжено нетривиальным деструктором — то деструктора нет.

Конструируемые строки в static_assert

Для начала придумали понятие «невычисляемая строка» (unevaluated string): закавыченная строка, значение которой не проходит в скомпилированную программу, а нужно только компилятору. Они являются частью _Pragma, asm, [[nodiscard]]… — и, конечно, static_assert. Автоматически считается, что они в единой для компилятора кодировке трансляции, покрывающей текущий и будущий Юникод, кроме, возможно, половинок суррогатных пар. Им запрещается иметь префикс кодировки, часть заэкранированных символов (нестандартные и однобайтовые).

Впоследствии позволили в static_assert любую константно вычисляемую строку:

// Было
template <typename T, auto Expected, unsigned long Size = sizeof(T)>
constexpr bool ensure_size() {
  static_assert(sizeof(T) == Expected, "Неожиданный sizeof");
  return true;
}
static_assert(ensure_size<S, 1>());
// Остаётся надеяться, что компилятор напишет, что дело было в ensure_size<int, 1, 4>

// Стало
static_assert(sizeof(S) == 1,
    std::format("Неожиданный sizeof: хотел 1, получил {}", sizeof(S));
// Неожиданный sizeof: хотел 1, получил 4

Сам constexpr format намеренно не внесён, но его прообраз, библиотека libfmt, уже способна на constexpr.

i-й элемент пакета параметров

Теперь его можно получить как T...[i]. Например: void f(T&&... t) { g(std::forward<T...[0]>(t...[0])); }.

Формально это несколько бьёт по имеющемуся коду: void f(T...[0]){} представляло собой пакет безымянных массивов, но по факту не покрыто тестовыми программами и даже не компилировалось в MSVC и G++. C# и D поддерживают и i-й параметр с конца, но отрицательные числа для этого ошибкоопасны, а более сложный синтаксис решено не просить.

Эта функциональность, написанная на шаблонах, даёт O(n) специализаций. В CLang, а за ним и в G++ реализовано «волшебным» (встроенным в компилятор) шаблоном __type_pack_element<i, Types...> и используется, например, в variant.

Имя _ может повторяться

auto [where, _] = insert(); — давно устоявшаяся манера программирования, когда функция возвращает два поля, а нужно одно, особенно если возвращается неговорящий тип вроде pair. Второй вариант — идиома RAII требует именованный (не временный) объект, но имя не используется: захват мьютекса lock_guard _(someMutex). На случай, когда таких подчерков несколько, идиому расширили:

namespace a {
  auto _ = f();
  auto _ = f(); // Остаётся ошибка: с глобальными переменными не работает
}
int _;
void f() {
  using ::_;   // Остаётся OK, добавление в пространство имён постороннего символа
  auto _ = 42; // Теперь OK
  using ::_;   // Остаётся ошибка: using _ разрешено только до локальной _
  auto _ = 0;  // Теперь OK
  static int _; // Остаётся ошибка: со статическими переменными не работает
  {
    auto _ = 1;       // Остаётся OK, замещение
    assert( _ == 1 ); // Остаётся OK, имеем дело с замещённой переменной
  }
  assert( _ == 42 );  // Ошибка: которая из двух?
}

Правила языка получились простые.

1. Заглушкой является переменная _ — локальная (automatic storage duration), неглобальная структурная, нестатическое поле, переменная-перехват в лямбда-функции. Действительно, для функций, типов, глобальных переменных, using X=Y, концепций и шаблонных параметров новый механизм бесполезен: этим объектам либо нужно говорящее имя, либо Си++ уже даёт подходящие механизмы вроде безымянных типов.
2. Имя _ (независимо от того, годится ли объект на роль заглушки) можно использовать, пока не объявят подчерк-заглушку в том же блоке.
3. Использование или неиспользование подчерка-заглушки не должно вызывать предупреждений.

Расширен constexpr

• Преобразование указателей в void*, а потом обратно в свой тип. Преобразование в посторонние типы неконстантно. Используется для так называемого стирания типа — при выполнении информация хранится в переменной общего типа, но её обработка выстраивается так, что все преобразования в частный тип верны. (Так устроены, например, обобщённые типы Java.) В CLang механизм уже есть (потребовался для выделения памяти) и вынести наружу ничего не стоит, G++ и EDG не видят препятствий. По заявлениям Г. Саттера, это шаг к constexpr format.
• Предыдущее изменение привело к тому, что теперь можно сделать constexpr placement new, допустимый только если указатель действительно смотрит на свой тип, и являющийся простой инициализацией. Воспользовавшись нововведением, перенесли в constexpr библиотеку неинициализированной памяти (Си++17).
• Constexpr-указатели, ссылки и структурные переменные, представляющие собой просто название по имени того или иного constexpr-объекта.
• Выброс исключений с последующей обработкой. Но в любом случае авария не должна выпадать наружу, иначе это не constexpr: вычисляется при исполнении, если контекст позволяет, и ошибка — если нет. Раньше уже факт выброса снимал constexpr. Некоторым наиболее распространённым исключениям сделан constexpr what(). Мотивация — при константных вычислениях иногда случаются ошибки, и нужно принудить компиляторы выводить в консоль диагностические сообщения, а не общее «выброшена ошибка std::invalid_argument».

Вариативный friend

Одно из назначений оператора friend — объекты-утилиты, сделанные через саморекурсивные шаблоны. Если шаблон вариативный, то друзей может быть много.

Пример: так называемый passkey, идиома Си++, используемая, если скрытую функцию надо вызвать из несвязанного шаблона (обычно make_unique/make_shared). Чтобы шаблон имел к ней доступ, функция должна быть общедоступной, и скрывают не её, а параметр-затычку, так называемый passkey, который так просто не сконструируешь.

// Вариативный passkey
template<class... Ts>
class Passkey {
  friend Ts...;
  Passkey() {}
};

class C {
public:
  // Можно вызвать только из Blarg, Blip и Baz
  void intentional(Passkey<Blarg, Blip, Baz>);
};

// Раскрыть класс для внутренних объектов
template<class... Ts>
struct VS {
  template<class U>
  friend class C<Ts>::Nested...;
};

Разрешение вариативных шаблонных перегрузок с концепциями

Для простой шаблонной перегрузки с концепциями 1-2 уже прописано: если подходят несколько шаблонных функций, брать ту, чья концепция сильнее (у́же). То же самое сделано и для вариативной 3-4, очень сложным языком. «Почти правильный» код Си++23 может перестать компилироваться в 26.

template <std::ranges::bidirectional_range R> void f(R&&); // №1
template <std::ranges::random_access_range R> void f(R&&); // №2

template <std::ranges::bidirectional_range... R> void g(R&&...); // №3
template <std::ranges::random_access_range... R> void g(R&&...); // №4

void call() {
    f(std::vector{1, 2, 3}); // OK, №2 сильнее
    g(std::vector{1, 2, 3}); // Теперь OK, №4 сильнее
}

=delete("причина")

Иногда нужно отказаться от автоматического присваивания, одной из унаследованных функций или нежелательного преобразования типа. В Си++03 функцию удаляют заголовком без тела, по возможности скрытым private: void f();. В Си++11 появилось тело =delete: компилятор, а не линкер явно сообщает о недопустимом вызове. По словам заявки, «автор библиотеки говорит: „Я знаю, что вы думаете делать, и это неверно“». И в том, и в другом случае функция участвует в разрешении перегрузок.

Нововведение дополнительно сообщает программисту, почему функция удалена и что делать — «…и это неверно, и я скажу, почему неверно и как надо». Например: Proxy<T> factory(const T&&) = delete("Опасно висячими ссылками");. Другие приведённые в источнике причины: старый API выброшен и отсылает на новый, некопируемый/труднокопируемый тип, недопустимое конструирование строки из nullptr, неправильный синтаксис создания динамического массива функцией make_unique.

Существуют предложения сделать условный =delete, как это сделали с explicit(bool) (Си++20) и noexcept(bool) (Си++11), но, по заверениям заявки, данный синтаксис не бросит на это тень.

Пакеты в структурных переменных

Синтаксический сахар для сложных шаблонов, разбирающих объект-кортеж на части. Это работало и раньше — только на уровне библиотеки.

auto [x,y,z] = f();  // обычная структурная переменная
auto [...xs] = f();  // новое
auto [x, ...rest] = f();  // тоже новое

// Новое: чтобы помножить кортеж на кортеж, оба рассматриваем
//  как структурные переменные
template <class P, class Q>
auto dot_product(P p, Q q) {
    auto&& [...p_elems] = p;
    auto&& [...q_elems] = q;
    return (... + (p_elems * q_elems));
}

Расширенные самопроверки (контрактное программирование)

Пока сделали минимально действующий продукт, с тремя операторами: предусловие, постусловие и самопроверка.

int f(const int x)
  pre (x != 1) // предусловие
  post (r : r != x) // постусловие
{
  contract_assert (x != 3); // самопроверка
  return x;
}

Пока отсутствуют:

• Включение самопроверок в систему типов — пока самопроверки никак не изменяют тип функции.
• Инварианты (одновременно предусловие и постусловие).
• Возможность обратиться к исходным значениям переменных в постусловии.
• Семантика, похожая на assume — компилятор предполагает, что условие выполняется, и оптимизирует код из этого предположения.
• Более наглядный показ, что собой представляет запрограммированный алгоритм.
• Деление самопроверок на уровни, которые можно включать и выключать по отдельности.
• Постусловия для функций, из которых нет выхода, или есть выход только аварийный.
• Самопроверки, которые исполнимы только при компиляции.
• Сохранение состояния от одной самопроверки к другой — «функция вызывается только один раз».
• Более сложные протоколы, чем вызов одной функции — например, перед работой с файлом нужно вызвать fopen.

Шаблоны на концепциях

Проще всего объяснить примером: понятие «диапазон целых» обобщается в «диапазон чего-то».

// Было
template<typename T>
  concept range_of_integrals = std::ranges::range<T>
       && std::integral<std::remove_cvref_t<std::ranges::range_reference_t<T>>>;

// Стало
template<typename T, template <typename...> concept C>
  concept range_of = std::ranges::range<T>
       && C<std::remove_cvref_t<std::ranges::range_reference_t<T>>>;
template<typename T>
  concept range_of_integrals = range_of<T, std::integral>;

Разработчики писали подобное на лямбда-функциях:

template <typename T, auto ConceptWrapperLambda>
  concept decays_to = requires {
    ConceptWrapperLambda.template operator()<std::decay_t<T>>();
  };
template <class T> requires decays_to<T, ([]<std::copyable>(){})>
auto f(T&& x) {}

Рефлексия при компиляции

В июне 2025 года приняты целых семь статей.

Си++ получил две новых операции — «баян» и «кошачьи ушки», а также оператор template for.

Операция «кошачьи ушки» (метаинформация) constexpr auto mInt = ^^int; переводит объект Си++ (тип, поле…) в информацию о нём. Операция «баян» (материализация) [:mInt:] x = 1; — наоборот. Все операции с метаинформацией автоматически consteval (выполняются только при компиляции).

Оператор template for разворачивается в последовательность вызовов, и хорош и без метаинформации:

struct S {};
long result = 0;
template for (auto x : s)
    result += sizeof(x);

С метаинформацией можно проводить разные преобразования, для этого есть std::meta, целая «волшебная» (определённая в компиляторе) библиотека.

Простейший пример — почленное хэширование. ^^T — получить метаинформацию о типе. nonstatic_data_members_of — есть метаинформация о типе, получить список полей. t.[:mem:] — «материализовать» метаинформацию в реальное поле объекта.

template <typename H, typename T> requires std::is_standard_layout_v<T>
void hash_append(H& algo, T const& t) {
  constexpr auto ctx = std::meta::access_context::unchecked();
  template for (constexpr auto mem : nonstatic_data_members_of(^^T, ctx)) {
      hash_append(algo, t.[:mem:]);
  }
}

Редакционные правки

• Закрыты разночтения в лексическом анализаторе: сращиванием строк текста через \⤶ и склеиванием лексем через препроцессорное ## можно получить имя символа; переводы строк внутри закавыченной строки запрещены. Это статус-кво, поддерживаемый G++, CLang и EDG.
• Некодируемые строковые литералы (например, из-за отсутствия конкретного символа в кодировке исполнения) ошибочны.
• Уточнены правила игнорирования стандартных атрибутов:
  • Стандартный атрибут должен быть корректным по правилам текущего Си++, даже если игнорируется. (Уже в Си++23 и только добавлено примечание.)
  • У стандартных атрибутов необязательная семантика: убирание атрибута из корректной программы может менять её внешнее поведение, но не может придумывать новое — лишь ограничить до одного из допустимых вариантов, когда атрибут есть, и, возможно, убрать какие-то компилятороспецифичные гарантии. (Также в Си++23 и добавлено примечание.)
  • Псевдофункция препроцессора __has_cpp_attribute должна проверять, реагирует ли компилятор на данный атрибут (а не разбирает ли) — а если разбирает, но не реагирует, атрибут бесполезен и макросы совместимости должны развёртываться во внутренние функции вроде __builtin_assume. (А это новое правило.)
• Объявлено, что объект initializer_list ссылается на опорный массив, который может появиться в памяти двумя способами: как временный объект или как ссылка на какой-то массив, чьё время жизни продлено. Другими словами, нет нужды копировать из сегмента данных на стек, теряя в производительности и надёжности.
• Требования к generate_canonical переписаны так, чтобы работало на недвоичных машинах, сохранялись статистические свойства на всём диапазоне [0,1) — и результирующее число никогда из-за недостатков дробной арифметики не стало бы единицей. В результате может нарушиться взаимоповторяемость с Си++23 — на том же генераторе случайных битов могут выходить другие дробные.
• Переписано, когда можно опускать скобки при агрегатной инициализации: Point x[2] = { 1, 2, 3, 4 };.
• Заголовок модуля export module Name; не может быть макросом — это усложняет его обработку системой сборки. Импорт может — не вызывает таких сложностей.
• Пустой бесконечный цикл — больше не неопределённое поведение. CLang в таких ситуациях почему-то исполнял посторонний код.
• Выкинуты все [[nodiscard]] из стандарта в отдельный документ, описывающий оптимальную практику, в каких случаях его применять. Предполагается, что изменения в этот документ будут вноситься легче, чем в стандарт. Один пример: правило MISRA C++ 28.6.4 запрещает вызывать как процедуры remove[_if], unique и empty — на empty аннотация была, чтобы не путали с clear, а на остальных не было (результат нужен в дальнейшем resize/erase).
• Упрощены грамматические правила для литералов.
• Уточнена работа операций сравнения в expected.
• На стыке диапазонов, алгоритмов и разрешения перегрузки в пространствах имён возник специфичный вид объектов, призванных не вызывать функции из <algorithm> — ниблоиды (niebloids), в честь Эрика Ниблера, автора библиотеки диапазонов. Реализованы Ниблером в изначальной библиотеке, подхвачены G++, CLang и Microsoft, и их узаконили.
• Функции, работающие с непрерывными итераторами, получили официальное право преобразовывать их в указатели.
• Объяснено, как atomic и atomic_ref могут работать с volatile-объектами. Первый — никак. Второй — только если структура объекта допускает это напрямую, без мьютекса: например, объект в системной памяти и у него семантика volatile, а для доступа между потоками одной программы нужен atomic.

Гармонизация с Си

• В набор символов внесены остатки печатного ASCII @$`, которые могут пригодится впоследствии. Ранее в Си23 добавили @$, в первую очередь из-за EBCDIC — оба символа в разных диалектах кодировки на разных позициях.
• Выкинут strtok из автономной библиотеки вслед за Си, так как содержит внутреннее состояние. Большинство реализаций используют потоколокальные переменные, которые в автономной среде могут отсутствовать.
• Переписан макрос assert, чтобы лучше поддерживались шаблоны и многомерная индексация, коих просто не существовало на момент появления препроцессора Си.
• Новые библиотеки Си23 stdbit.h и stdckdint.h, без Си++-аналогов <cstdbit/cstdckint>.

#embed — внедрение двоичных данных

Очень часто нужно вставить в программу двоичные данные в форме «как есть» — заявка упоминает «чистый» образ файловой системы, который надо развернуть, когда пользователь просит полный сброс устройства, PNG-иконку, встроенные в программу скрипты на другом языке. Разработчики на Turbo Pascal могут вспомнить программу binobj и функцию Graph.InstallUserDriver.

Конструкция constinit const unsigned char data[] = { 1, 2 }; создаёт непропорционально много лексем, и хороший синтаксический движок CLang как-то справляется с ней, а другие компиляторы могут «зависнуть» надолго: 4 мегабайта данных компилируются от 8 секунд (CLang) до минуты (MSVC), а внедряются — за долю секунды.

const unsigned char icon_display_data[] = {
    #embed "art.png"
};

Директива уже есть в стандарте Си23.

Преобразование данных из порядка байтов заведомо Intel/Motorola в машинный, важное для числовых таблиц (например, баллистических) не предусмотрено. Все примеры из заявки оперируют типом (unsigned) char, которому преобразование не нужно. Впрочем, немалое количество больших массивов — это не слова и более крупные единицы, а именно байтовые данные: PNG, UTF-8, исполняемый файл, образ диска…

Библиотека

Разные изменения в библиотеке

• Простейшая библиотека идентификации кодировки исполнения.
• Получение системного дескриптора из fstream. Может использоваться в высоконадёжном программировании, когда надо гарантированно записать данные на диск.
• Поддержка отладчика. Новый заголовочный файл <debugging> с тремя функциями: breakpoint(), breakpoint_if_debugging(), bool is_debugger_present().
• Теперь объект ignore применим не только в tie: std::ignore = foo();.
• type_info из Си++23 получил кроссплатформенный порядок.

Автономная библиотека

Автономная (freestanding) библиотека не полагается на системные вызовы (даже выделение памяти), выброс исключений (требует серьёзной работы со стеком), может быть написана даже на чистом Си++ и потому полностью кроссплатформенна.

• Возможен (не обязателен) operator new, возвращающий nullptr, приводящий к системной аварии или делающий что угодно по желанию реализатора. Добавлен макрос __cpp_lib_has_default_operator_new, проверяющий, возможно ли выделение памяти — например, вместо динамического std::vector могут использоваться массивы ограниченного размера.
• Множество функций Си, включая строковые и математические, а также <charconv> и char_traits.
• algorithm, array, optional, variant, string_view. Переписаны монадные функции optional так, чтобы не ссылались на неавтономный (выбрасывающий исключения) value.
• expected, span, mdspan.
• numeric, random

Новые constexpr

• Устойчивая сортировка.
• consteval bool is_within_lifetime(&union_.field) — «волшебная» (реализованная внутри компилятора) функция, проверяющая, держит ли union то или иное поле. Тип union при компиляции изначально (с Си++11) помеченный на манер variant, Си++20 позволил менять активное поле при компиляции, а доступ к другому полю отключает constexpr. Используется для экстремальной оптимизации по памяти с сохранением константности — например, для однобайтового optional<bool>.
• Больше математических функций, включая комплексные.
• Библиотека неинициализированной памяти, в constexpr-контексте или ничего не делающая, или проводящая простое присваивание.
• atomic, atomic_ref. Многозадачности при компиляции, это, разумеется, не даст, но позволит выполнять такой код хоть в один поток.
• Многие части стандартных контейнеров, включая deque и map.
• Замена для integral_constant: тип constant_wrapper и шаблонная константа cw.
• Немалое количество сценариев для format.

Перевод данных в строку и наоборот

• from_chars_result получил operator bool — проверку кода ошибки.
• to_string для дробных выдаёт то же, что и format("{}", x). А он, в свою очередь, то же, что to_chars — в компактном точном нелокализованном виде с целой частью. Ранее он был унифицирован с printf("%f", x), то есть обращался к глобальной локали (ненадёжно, да и вычисление нужных параметров локали затратно) и плохо работал со слишком большими/малыми числами. Это нарушение совместимости, но to_string значительно реже других методов перевода чисел в строку. Проверив случайные 100 вызовов, авторы обнаружили, что только семь из них дробные, в одном явная ошибка — запись в INI в локализованном виде, а остальные используются для отладки.
• stringstream можно инициализировать строками string_view.
• То же самое с bitset.
• string + string_view. Изначально в операции отказали из-за особенностей архитектуры LLVM — всё, что можно, она исполняет «лениво», и append точками следования фиксирует, где исполнять, а сложение в большом выражении может выйти за время жизни string_view. Так что целых пять редакций — это попытка найти наиболее удачную реализацию.
• string.subview — синтаксический сахар для получения подстроки как string_view. Заявленная цель: роль обычного string’а сжалась до объекта промежуточного хранения, и часть функций string’а уже принимают string_view, но ни одна не производит. Ограничения на именованный (не временный) this решили не делать: string_view короткоживущ, буфер с данными почти всегда переживает его, а программист обычно ознакомлен с опасностями string_view и должен сам следить за временем жизни объектов.

format (Си++20)

• Унифицировано форматирование указателей.
• Параметры ширины теперь также проверяются при компиляции.
• Форматирование строк, заранее не известных: std::vformat(str, std::make_format_args(path.string())); → std::format(std::runtime_format(str), path.string());. Первое предназначено для писателей своих обёрток над форматированием вроде doLog(str, args...), а не для конечных пользователей, и в пользовательском коде опасно: make_format_args содержит string_view, и если его вытащить в отдельную переменную, string_view будет жить дольше, чем временная строка. Для надёжности тонкая обёртка runtime_format_string принимается только по временной ссылке.
• В само́м make_format_args избавились от std::forward и временных объектов, делая форматирование более устойчивым к висячим ссылкам.
• Серьёзная ошибка, ранее случившаяся в fmt (прообразе format): кодовые единицы char, будучи отформатированы как числа или с «широкой» форматной строкой, выдавали зависящий от реализации вид. Теперь char, отформатированный как число, будет unsigned; отформатированный как символ в широком контексте — символом с кодом 0…255.
• Форматирование path.

print (Си++23)

• println() без параметров.
• print может захватывать или не захватывать мьютекс консоли в зависимости от того, как происходит преобразование: преобразовать в строку целиком, потом вывести (например, для чисел), или параллельно преобразование-вывод (например, для массивов).

Функциональное программирование

• Добавлена copyable_function, построенная по принципу новой move_only_function (Си++23) и много легче, чем function (Си++11), которая один из самых тяжёлых типов STL. Последнюю всё-таки решили не запрещать.
• Добавлена совсем лёгкая function_ref, не инкапсулирующая вызываемый объект, а просто ссылающаяся на него. Может использоваться для callback’ов, если основная функция тяжёлая или виртуальная, и не хочется делать её шаблонной. Класс писали своими силами: в заявке приведены шесть реализаций, некоторые на Си++14, и три из них назывались function_ref.
• Добавлен облегчённый шаблонный карринг через bind_front, если вызываемый объект (например, слот Qt) вычисляется раз и навсегда при компиляции.
• This-параметры из Си++23 позволили внести одну из перегрузок visit внутрь variant.

Метапрограммирование

• std::is_virtual_base_of — важно при преобразовании указателей из типа в тип. Приведён пример: в зависимости от того, виртуальный целевой указатель или нет, weak_ptr переносится из типа в тип через сильный указатель или напрямую.
• Объект monostate продублирован в <utility>. Заявленных целей две: это тип со средним количеством функциональности — создание, копирование, сравнение — и его удобно применять для испытания собственных объектов хранения. Вторая — в библиотеке (например, в future) функциональность «ничего не возвращает» сделана через псевдотип void, но на такое способны разве что специалисты высшего класса, писавшие стандартную библиотеку. Среднему программисту проще это сделать через пустую структуру monostate.

Хранение данных

• Добавлен hash для календарных типов.
• Добавлен weak_ptr.owner_hash и несколько других подобных функций.
• Закончен разнородный поиск в [unordered_]set/map: добавлены шаблонные insert, insert_or_assign, try_emplace, operator[], bucket. Разнородный поиск начат в Си++14, и позволяет хранить с «тяжёлыми» ключами (string), а искать по «лёгким» (string_view или даже const char*). Программист сам включает разнородный поиск (полем-типом CompareObject::is_transparent) и задаёт набор допустимых ключей.
• Операции сравнения для reference_wrapper.
• Возможность писать std::find(v.begin(), v.end(), {3, 4});. Для этого всего лишь в шаблоны типа template<class T, class Allocator, class U> добавили class U=T, которое работает, когда тип ключа определить невозможно.
• Кортежи: сравнение на равенство, обмен.

inplace_vector — простейший массив переменной длины

Массив переменной, но ограниченной длины, основанный на обычном массиве. Этот контейнер часто пишут собственными силами — скажем, boost::static_vector<T, Capacity>. Нужен, если даже обычный вектор слишком тяжёлый, или менеджер памяти недоступен (в автономной/безопасной среде, на очень ограниченных машинах). Constexpr, если внутренний тип тривиальный. Тривиально копируемый, если внутренний тип тривиально копируемый.

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

indirect и polymorphic — аналоги unique_ptr

Представляют собой указатели единоличного доступа. Семантически это объекты-значения, с такими отличиями от старого unique_ptr:

• есть конструктор копирования, копирующий объект;
• const-доступ делает константным и объект;
• для удобства могут и не содержать объекта, и для этого есть функция, именуемая valueless_after_move, но эта семантика не поощряется и лучше null object и/или optional;
• может применяться оптимизация малых буферов.

Разница только в том, что indirect поддерживает только свой тип (и годится, например, для идиомы pimpl), а polymorphic — любой производный, и потому «под капотом» содержит инфраструктуру для подбора нужного конструктора копирования.

Улей — неперемещающий динамический список

Улей (hive) — специализированный менеджер памяти для однотипных данных, используемый в играх и скоростной торговле. Никогда не перемещает, объект вставляется в случайное место, быстры операции «проход», «добавление» и «удаление».

optional<T&>

Обёртка вокруг указателя, очень простой тип, который программисты часто пишут своими силами. Обычно применяется для передачи параметров в функцию, возвращается в результате поиска по набору. Имеет преимущества перед указателем:

• Запрещает арифметику указателей, что даёт плюс к безопасности кода.
• Сразу объясняет, что это за указатель: ссылка на объект или ничего. Владение объектом не передаётся, уничтожает тот, кто и раньше за него отвечал.
• Позволяет все утилиты, имеющиеся в optional «из коробки»: итератор, монадные функции…

Диапазоны и другие представления данных

• Переписан projected (внутренний тип библиотеки диапазонов), лучше работающий с указателями на недоопределённые классы (class Opaque;). Многие из функций диапазонов не работали там, где работал «голый» STL.
• Комплексным числам добавлено get<0> и <1>, как обычным кортежам (tuples).
• basic_const_iterator можно получить из неконстантного собрата.
• views::concat.
• ranges::generate_random — стандартная версия простейшая, но авторы библиотек могут добавлять к генераторам/распределениям нестандартные функции, чтобы получать сразу много случайных чисел. Какие именно — стандарта пока нет.
• Объекту std::optional даны итератор, begin и end — то есть он тоже стал диапазоном.
• Выкинуто invocable<F&, iter_common_reference_t> из многих концепций, связанных с итераторами, что позволило итераторы-заместители (vector<bool>).
• views::cache_latest.
• ranges::reserve_hint — обычно применяется для представлений (views), и приближённо прикидывает, сколько там элементов. Связано это с Юникодом: малая доля букв имеет верхний регистр, и совсем немного — верхний регистр не из одной буквы, так что для условного uppercase_view можно предположить, что ожидаемая длина — это длина исходной строки (а может, немного больше)..
• views::to_input — переводит представление в самый простой вид, чтобы дальнейшие алгоритмы не пытались реализовать продвинутую функциональность, видя, например, представление прямого доступа.
• views::indices — немалое количество случаев вызова объекта iota начинается с нуля. И тут злую шутку играет x64: размеры объектов — unsigned long long, и iota(0, x.size()) не компилируется. Если для нешаблонного кода можно написать 0uz, то для шаблонного обходной путь довольно сложен.

span (Си++20) и mdspan (Си++23)

• Функция submdspan, производящая слайсинг многомерных массивов. На выходе получается mdspan (Си++23), возможно, с нестандартным типом внутри.
• Конструктор span(initalizer_list), не требующий промежуточного объекта вроде массива. Время жизни некоторых initializer_list ограничено, и программисты, работающие со string_view и span, привыкли проверять его.
• span.at(i), выкидывающий аварию.
• mdspan с излишним выравниванием.
  • Впоследствии сделали объект для излишнего выравнивания — aligned_accessor.
• Улучшено угадывание статических (устанавливающихся при компиляции) габаритов mdspan, если таковые имеются.
• std::mdspan<float, std::dextents<2>> a; — не столько для краткости, сколько для угадывания шаблонных параметров: mdspan a(storage.data(), height, width);

Параллельное программирование

Разное

• Параллельные операции на диапазонах.

Атомарный API

• atomic_fetch_min/max — вычисление минимума/максимума атомарной переменной и обычной, и запись полученного обратно в атомарную. Заявленные задачи: бывает аппаратно (POWER) и высокоуровневая реализация неоптимальна, существует в библиотеках вроде OpenCL, част как алгоритм.
• atomic_ref может давать указатель на неатомарный объект. Заявленные задачи: старый API на volatile; отход от атомарного доступа к неатомарному; атомарный доступ к полю объекта, а не ко всему объекту вместе; адрес вообще не надо разыменовывать (например, чтобы различать объекты).

Read-copy-update

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

// Было — блокирующая версия
Data* data_;
std::shared_mutex m_;

template <typename Func>
auto reader_op(Func fn) {
  std::shared_lock<std::shared_mutex> l(m_);
  Data* p = data_;
  return fn(p);
}

void update(Data* newdata) {
  Data* olddata;
  { std::unique_lock<std::shared_mutex> wlock(m_);
    olddata = std::exchange(data_, newdata);
  }
  delete olddata;
}

// Стало — не блокируются только читатели
std::atomic<Data*> data_;

template <typename Func>
auto reader_op(Func fn) {
  std::scoped_lock l(std::rcu_default_domain());
  Data* p = data_;
  return fn(p);
}

void update(Data* newdata) {
  Data* olddata = data_.exchange(newdata);
  std::rcu_synchronize();
  delete olddata;
}

Hazard pointer

Главный недостаток идиомы read-copy-update в данном исполнении — не ждут только читатели, писатель может надолго «зависать». Это «зависание» означает, что другие читатели работают и держат объект, но не всегда допустимо.

Hazard pointer дополнительно следит, какие потоки пользуются тем или иным объектом, и как только объект перестаёт использоваться, он исчезает.

Идиома похожа на подсчёт ссылок, но подсчитывает только локальные ссылки из функций доступа — а не глобальные ссылки между объектами. Это позволяет циклические ссылки без слежения, чей «ранг» выше (от «контейнеров» к «содержимому» — shared_ptr, в прочие стороны — weak_ptr), а также без присущего shared/weak_ptr управляющего объекта, исчезающего, когда исчезнет последний слабый указатель.

Система сделана беспрепятственной по записи ценой повышенного расхода памяти: read-copy-update хранит одно поколение старых данных, а hazard pointer — сколько угодно.

Поскольку G++ всё ещё держит совместимость двоичных интерфейсов, на будущие дополнения оставили 4/8 байтов на объект.

(Старая блокирующая версия — та же)

// Стало — не блокируется и писатель
struct Data : std::hazard_pointer_obj_base<Data> {}
std::atomic<Data*> pdata_;

template <typename Func>
auto reader_op(Func userFn) {
  std::hazard_pointer h = std::make_hazard_pointer();
  Data* p = h.protect(pdata_);
  return userFn(p);
}

void writer(Data* newdata) {
  Data* old = pdata_.exchange(newdata);
  old->retire();
}

Фреймворк асинхронно-параллельного исполнения

Предполагается, что немалые части этой библиотеки будут написаны не на Си++. Два главных объекта — планировщик (scheduler) и задача на исполнение (sender), оба — концепции (sender auto). Для тех, кто сам пишет планировщики, есть объект receiver для этой же задачи.

using namespace std::execution;

scheduler auto sch = thread_pool.scheduler();

sender auto begin = schedule(sch);
sender auto hi = then(begin, []{
    std::cout << "Hello world! Have an int.";
    return 13;
});
sender auto add_42 = then(hi, [](int arg) { return arg + 42; });

auto [i] = this_thread::sync_wait(add_42).value();

Антон Полухин из Яндекса считает, что пока у этой системы есть недостатки: она устроена на шаблонах и концепциях (нет единого полиморфного объекта для передачи между библиотеками), и крайняя низкоуровневость.

В ноябре 2024 добавили объекты prop и env.

В июне 2025 добавили первую параллельную реализацию.

Математика

• В библиотеку рациональных чисел (Си++11) добавлены новые приставки СИ ронна-, ронто-, кветта-, квекто-.

Арифметика с насыщением (упором в край)

Стандартная работа беззнаковых типов — арифметика остатков: при переходе через $2^{n}$ значение превращается в 0. Знаковые — зависят от реализации. Но это не всегда нужно: заявка упоминает расчёт цветов (RGB) в компьютерной графике, когда непойманное переполнение даёт простые 255. Никакой защиты от дурака нет. Поддерживаются четыре арифметических действия и преобразование типов. Деление с упором div_sat при делении на ноль перестаёт быть константным.

# include <numeric>

// Считаем, что у нас 8-битный char и отрицательные в дополнительном коде
int x1 = add_sat(3, 4);               // 7
int x2 = sub_sat(INT_MIN, 1);         // INT_MIN
unsigned char x3 = add_sat(255, 4);   // 3!! — работа в int и преобразование 259 → 3
unsigned char x4 = add_sat<unsigned char>(255, 4);   // 255
unsigned char x5 = add_sat(252, x3);  // Ошибка, нет нужной перегрузки
unsigned char x6 = add_sat<unsigned char>(251, x2);  // 251!! — преобразование INT_MIN → 0
unsigned char x7 = saturate_cast<unsigned char>(-5);  // 0

Заполненная линейная алгебра

Добавились BLAS-подобные алгоритмы линейной алгебры для заполненных (большей частью ненулевых) векторов и матриц. Мотивация:

• Комитет Си++ сам поставил линейную алгебру приоритетом.
• Си++ — стандартная платформа для наукоёмкого ПО, которому линейная алгебра более чем нужна.
• Это как сортировка массива: примитивные алгоритмы медленные, а самые быстрые реализации можно получить аппаратно-специфичными улучшениями.
• В стандарте Си++ и так много разной математики — и умножение матриц не менее важно, чем функции Бесселя.
• BLAS — известный стандарт линейной алгебры, мало менявшийся с годами.
• Это такой же путь к интеграции в Си++ сторонних стандартов, как Юникод (идёт работа) и часовые пояса.

Конструкция полностью шаблонная и на mdspan. Преимущества перед стандартным BLAS:

• Работают любые типы, в том числе смешанные (данные в float, расчёт в double), а не только четыре стандартных BLAS’овских.
• Можно оптимизировать работу с матрицами небольших жёстко заданных габаритов — например, через SIMD.
• С небольшими изменениями возможно будет запустить целый пакет заданий (например, для машинного обучения).

Пока вне рассмотрения: расширенные функции BLAS/LAPACK, разреженная алгебра, расчёты повышенной точности, тензоры («матрицы» с тремя и более измерениями), параллельная работа, перегрузка операций ±. Последняя — из-за неоднозначности (есть несколько типов умножения векторов), данные могут быть в одном типе, а работа в другом, и из-за больших объёмов памяти и многоступенчатых расчётов промежуточные буфера часто используются повторно.

Добавлены:

• Простейшие операции с матрицами вроде сложения
• Поиск, как надо повернуть вектор в 2D, чтобы одна из координат равнялась нулю (поворот Гивенса)
• Разные виды норм векторов и матриц
• Операции y := Ax, y := Ay, z := y + Ax для матриц общего вида, а также симметричных/эрмитовых/треугольных
• Операции A:=A + xyᵀ + yxᵀ, A:=A + αxxᵀ для симметричных/эрмитовых матриц (для эрмитовых матриц — вместо транспонирования соответственно эрмитово сопряжение)
• Операции A := xyᵀ, C := BA, C:=E + BA для матриц общего вида
• Операции C := BA, C := AC, C := CA, C:=E + BA для симметричных/эрмитовых/треугольных матриц
• Операция с симметричной/эрмитовой матрицей C :=C + αAAᵀ (матрица C была симметричной/эрмитовой и в результате ею останется, матрица A общего вида)
• Операция с симметричной/эрмитовой матрицей C:=C + ABᵀ + BAᵀ
• Решение треугольной СЛАУ, а также серии таких СЛАУ с общей матрицей

Нет даже решения заполненных СЛАУ. Вот одна из стандартных функций — решение треугольной СЛАУ на месте.

template<in-matrix InMat,
         class Triangle,
         class DiagonalStorage,
         inout-vector InOutVec>
void triangular_matrix_vector_solve(
  InMat A,
  Triangle t,
  DiagonalStorage d,
  InOutVec b);

Здесь пустой тип-тэг Triangle показывает, каким треугольником собрана матрица, верхним или нижним. Аналогичный тэг DiagonalStorage — что представляет собой диагональ матрицы A: явные значения или неявные единицы. В векторе b изначально правая часть системы, в результате расчёта будет решение.

Семейство инкрементальных генераторов псевдослучайных чисел Philox

В параллельных расчётах сложно получить псевдослучайность: если брать несколько независимых генераторов (multistream approach), то чем их инициализировать, чтобы не случилась атака «дней рождения», приводящая к плохому перемешиванию точек? Можно также брать 2‑е, 12‑е, 22‑е число (substream approach), но арифметический генератор потребует 10 пусков на каждое число. В таких случаях используют специальные инкрементальные (основанные на счётчике) генераторы псевдослучайных чисел — к счётчику (единицы машинных слов) прибавляется 1, затем обрабатывается очень слабым шифром. Потоки либо получают каждый по генератору с далёкими друг от друга значениями счётчика в уверенности, что последовательности не пересекутся (multistream approach), либо берут 2‑е, 12‑е, 22‑е число без потери производительности (substream approach).

В Си++ добавлено семейство инкрементальных генераторов Philox (2011), и две специализации philox4x32 и philox4x64. Поведение каждой жёстко заспецифицировано: 10 000-й запуск версии 4×32 даст число 1 955 073 260. Семейство широко распространено и независимо реализовано у NumPy, nVidia, AMD, Intel, Microsoft…

Поддержка SIMD

Сложная долго разрабатывавшаяся библиотека. Пример:

float * addr = ...;
void f(std::simd<double>x ) {
  x.copy_to(addr, std::simd_flag_convert |
            std::simd_flag_overaligned<16 >);
}

Работа с неопределённым поведением

observable — барьер для неопределённого поведения

Функция observable является барьером для неопределённого поведения — всё, что до неё, если само не является неопределённым, должно пройти нормально. Например, она может служить для автотестов на неопределённое поведение, или как барьер перед сомнительным действием.

void b(int &r, int *p) {
  if (!p) std::fprintf(stderr, "count: %d\n", ++r);
  std::observable();
  if (!p) std::fprintf(stderr, "p is null\n");
  *p += r;    // Из-за этой строки компилятор может считать, что p ≠ null
}

Функция не обязательно «магическая» (встроенная в компилятор); одна из возможных реализаций — доступ к volatile-переменной. На многозадачность никак не влияет и не заменяет межпоточную синхронизацию.

Не принято, но ожидается: любая проверка контракта — вызов этой же std::observable.

Укреплённая библиотека

Си++ много думает над тем, как сделать новый код безопаснее, но надо налаживать безопасность здесь и сейчас, тем более доклад Белого дома (февраль 2024) говорит, что Си++ — очень опасный язык. Предлагается новая версия стандартной библиотеки — укреплённая. Некоторые (пока немногие) предусловия, обычно выход за диапазон, превращаются в нарушение контракта.

Может быть вопрос: а зачем это, если и без контрактов будет аварийный останов? Может и не быть, а тихо испортить память или выдавать другие ошибки: разыменование пустого std::optional может выдать что угодно.

В последний момент (ноябрь 2025) добавлено: нарушения укреплённой библиотеки должны вызывать аварийный останов на месте — программа уже в некорректном состоянии.

Отложены

• Библиотечная поддержка сопрограмм (языковая есть в Си++20)
• Сеть — не удалось сделать модульный подход
• Некое pattern matching — возможно, оператор inspect, аналог switch, действующий даже на разные объектные подтипы и разные шаблоны строк
• Структуры данных
  • path_view, аналог string_view для путей. По факту variant, способный ссылаться без хранения на пути разных форматов и оперативно перекодировать в системный вид — rendered_path, буфер достаточно больших размеров с возможностью запросить ещё больше, выделив память.
• Многозадачность:
  • Параллельные очереди.
  • «Волокна», элементы стековой кооперативной многозадачности. Сопрограммы Си++20 бесстековые, то есть могут использоваться в любой среде, где есть setjmp/longjmp и выделение памяти (в автономной нет даже их).
• Прочее:
  • Улучшения в библиотеке диапазонов.

Переезжающие типы

Переезд объекта — полное разрушение объекта до неинициализированной памяти и создание идентичного в неинициализированном блоке — важная функция любого ABI, используемая, например, при «подчистке» временных объектов, возврате значения функции. Компилятор старается избавляться от переездов, создавая объект там, где его ожидает программа-потребитель, но это не всегда возможно.

Си++98 создавал копию, уничтожал имеющийся. Крайняя непроизводительность этого механизма и сделала оптимизацию возврата, никак не стандартизированную, но существующую почти во всех компиляторах. Перемещение объектов (Си++11) подняло производительность в важнейших случаях — тип T&& говорит, что объект ненужный и можно забрать из него ценные ресурсы (выделенную память, файловые дескрипторы и т. д.), оставляя объект опустелым, но корректным — ведь потом заработает деструктор. Так что резервы не исчерпаны: замечено, что многие нетривиальные объекты могут менять дислокацию значительно проще, чем конструктором перемещения и деструктором. И действительно, немало скоростных библиотек вроде RapidJson сами пишут ускоренный переезд.

Две новых концепции, связанные с производительностью:

• Тривиально переезжающий тип — объект достаточно перебросить в неинициализированную память бит в бит, а исходный бросить, не вызывая деструктор — и это будет корректный объект.
• Заменяемый тип — вместо уничтожения-создания достаточно вызвать операцию перемещения.

Эти понятия ортогональны: динамический массив (std::vector) с полиморфным выделением памяти только тривиально переезжающий (замена даст новые данные во владении старого менеджера памяти); строка, содержащая указатель на внутренний малый буфер, только заменяемая (указатель на внутренние поля не переезжает). И оба не тривиально конструируемые с перемещением.

Автоматически (без явного указания программистом) тривиально переезжают типы с заведомо тривиальными конструктором перемещения и деструктором (виртуальный деструктор и раньше снимал тривиальность!) — правда, компилятор и в Си++98 знал, что делать. В тех случаях, которые важны для производительности, компилятор не в состоянии определить эти свойства, и программист пишет «тривиально переезжающий (заменяемый) тип, если возможно» — компилятор проверяет, что все поля переезжают/заменяются, и делает таковой всю структуру.

struct Y trivially_relocatable_if_eligible {};
static_assert(std::is_trivially_relocatable_v<Y>);

В библиотеку неинициализированной памяти (Си++17) добавили функцию std::relocate — переезд объекта полным или сокращённым образом.

В последний момент (ноябрь 2025) выброшены из-за трудноустранимой проблемы. На некоторых архитектурах даже указатели не способны тривиально переезжать, что улучшает информационную безопасность, но приводит к непоследовательному поведению, а также терминологическому конфузу — «тривиальное» в Си++ всегда было «эквивалентное memcpy». Кроме того, важное место для переезда — обёртки со стиранием типа, когда непонятно, есть ли внутри такие непереезжающие указатели, и остаётся по старинке вызывать конструктор-деструктор. Если переезд и вернётся позже — то с подписью «зависит от реализации».