Первые новинки C++26: итоги летней встречи ISO

На недавней встрече комитет C++ активно взялся за C++26. Уже есть первые новинки, которые нас будут ждать в готовящемся стандарте C++:

• улучшенный static_assert,
• переменная _,
• оптимизация и улучшение для std::to_string,
• Hazard Pointer,
• Read-Copy-Update (так же известное как RCU),
• native_handle(),
• целая вереница классов *function*,
• множество доработок по constexpr,
• std::submdspan,
• и прочие приятные мелочи.

Для тех, кто предпочитает видеоформат

Если вам больше нравится слушать, чем читать, то этот пост доступен в формате видеолекции с C++ Zero Cost Conf. Кстати, там есть и другие интересные доклады. Надеюсь, вам понравится!

static_assert

static_assert — замечательный инструмент для диагностики неправильного использования класса или функции. Но до C++26 у него всё ещё оставался недостаток.

Вот, например, класс для реализации идиомы PImpl без динамической аллокации utils::FastPimpl из фреймворка userver:

template <class T, std::size_t Size, std::size_t Alignment> class FastPimpl final { public:      // ...     ~FastPimpl() noexcept { // Used in `*cpp` only         Validate<sizeof(T), alignof(T)>();         reinterpret_cast<T*>(&storage_)->~T();     }  private:     template <std::size_t ActualSize, std::size_t ActualAlignment>     static void Validate() noexcept {         static_assert(Size == ActualSize, "invalid Size: Size == sizeof(T) failed");         static_assert(Alignment == ActualAlignment,             "invalid Alignment: Alignment == alignof(T) failed");     }      alignas(Alignment) std::byte storage_[Size]; }; 

Пользователь класса должен предоставить правильные размер и alignment для класса, после чего можно заменять в заголовочных файлах std::unique_ptr<Pimpl> pimpl_; на utils::FastPimpl<Pimpl, Размер, Выравнивание> pimpl_; и получать прирост в производительности. static_assert внутри функции Validate() уже в cpp-файле проверят переданные пользователем размеры и если размеры неверные, выдадут сообщение об ошибке:

<source>: error: static assertion failed: invalid Size: Size == sizeof(T) failed <... десяток строк диагностики...> 

После этого у разработчика сразу возникает вопрос: «А какой размер правильный?» И тут незадача: подсказка располагается на десяток строк ниже сообщения об ошибке, в параметрах шаблона:

<source>: In instantiation of 'void FastPimpl<T, Size, Alignment>::validate() [with int ActualSize = 32; int ActualAlignment = 8; T = std::string; int Size = 8; int Alignment = 8]' 

Вот тут-то и приходит на помощь static_assert из C++26:

private:     template <std::size_t ActualSize, std::size_t ActualAlignment>     static void Validate() noexcept {         static_assert(                 Size == ActualSize,                 fmt::format("Template argument 'Size' should be {}", ActualSize).c_str()         );         static_assert(                 Alignment == ActualAlignment,                 fmt::format("Template argument 'Alignment' should be {}", ActualAlignment).c_str()         );     } 

Начиная с C++26, можно формировать сообщение об ошибке на этапе компиляции, а результат передавать вторым аргументом в static_assert. В результате диагностика становится намного лучше, а код становится приятнее писать:

<source>: error: static assertion failed: Template argument 'Size' should be 32 

Переменная _

Посмотрим на функцию подсчёта элементов в контейнере, у которого нет метода size():

template <class T> std::size_t count_elements(const T& list) {     std::size_t count = 0;     for ([[maybe_unused]] const auto& x: list) {         ++ count;     }     return count; } 

Алгоритм прост и понятен, но дискомфорт вызывает [[maybe_unused]]. Из-за него код становится громоздким, читать его неприятно. И убрать его нельзя, ведь компилятор начнёт ругаться: «Вы не используете переменную x, это подозрительно!»

<source>:12:19: warning: unused variable 'x' [-Wunused-variable] for (const auto& x: list) {                  ^ 

Зачастую в коде возникают ситуации, когда мы и не собираемся пользоваться переменной. Неплохо было бы это показать, не прибегая к большим и громоздким словам. Поэтому в C++26 приняли особые правила для переменных с именем _. Теперь можно писать лаконичный код, который похож на Python:

template <class T> std::size_t count_elements(const T& list) {     std::size_t count = 0;     for (const auto& _: list) {         ++ count;     }     return count; } 

Суперспособности переменной _ на этом не заканчиваются. В одном блоке кода может быть несколько таких переменных, но в то же время они будут разными и компилятор не даст вам обращаться к ним по имени _. При этом деструкторы для них вызываются так же, как и для обычных переменных:

std::unique_lock _{list_lock};  auto _ = list.insert(1); auto _ = list.insert(2); auto _ = list.insert(3);  auto [_, _, value, _] = list.do_something(); value.do_something_else();  // Вызываются деструкторы для каждой из _ переменных // в обратном порядке их создания 

std::to_string(floating_point)

Начиная аж с C++11, в стандартной библиотеке есть метод std::to_string для преобразования числа в строку. Многие годы он отлично работает для целых чисел, а вот с числами с плавающей точкой есть нюансы:

auto s = std::to_string(1e-7); 

Этот код вернёт вам не строку «1e-7», а строчку наподобие «0.000000». На этом сюрпризы не заканчиваются: есть возможность получить ту же строчку с другим разделителем «0,000000», если вдруг какая-то функция меняет глобальную локаль.

Из-за последнего пункта std::to_string(1e-7) ещё и медленный: работа с локалями для получения разделителя может тормозить сильнее, чем само преобразование числа в строку.

Всё это безобразие исправили в C++26. Теперь std::to_string обязан возвращать максимально точное и короткое представление числа, при этом не используя локали. Так что в C++26 std::to_string(1e-7) будет возвращать всегда «1e-7». Пусть это и ломающее обратную совместимость изменение, однако люди из комитета не нашли в открытых кодовых базах мест, где код бы сломался. Однако лучше подстраховаться заранее, и если вы используете std::to_string(floating_point), то лучше добавить побольше тестов на места использования.

Hazard Pointer

Радостная новость для всех высоконагруженных приложений, где есть что-то похожее на кэши. Начиная с C++26, в стандарте есть Hazard Pointer — низкоуровневый примитив синхронизации поколений данных (wait-free на чтении данных).

Другими словами, с помощью него можно делать кэши, работа с которыми не спотыкается о мьютексы, и работать с общей атомарной переменной (кэши линейно масштабируются на чтение по количеству ядер).

Давайте прямо сейчас сделаем свой кэш! Опишем структуру, которая хранит наши данные, и отнаследуем её от std::hazard_pointer_obj_base:

struct Data : std::hazard_pointer_obj_base<Data> { /* members */ }; 

Теперь заведём атомарный указатель на актуальное поколение данных:

std::atomic<Data*> pdata_; 

Чтение данных надо защитить через std::hazard_pointer:

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

Вся сложность в обновлении данных:

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

Мы меняем атомарный указатель, чтобы он указывал на новое поколение данных, но старые данные нельзя удалять сразу! Кто-то из читателей может продолжать работать со старым поколением данных из другого потока. Надо дождаться, пока всё поколение читателей не сменится. То есть дождаться, чтобы отработали все деструкторы объектов std::hazard_pointer, созданных на старом поколении данных, и только после этого удалять объект. Для этого зовётся old->retire();.

Метод retire() удаляет объекты, для которых нет активных читателей. Если читатели для old всё ещё есть, то выполнение программы продолжится, а объект будет удалён позже, когда это будет безопасно: при вызове retire() для другого объекта или при завершении приложения, если retire() больше никто не позовёт.

Read-Copy-Update (RCU)

Hazard Pointer хорошо подходит для небольших кэшей. Однако когда ваши кэши занимают несколько гигабайт, вы вряд ли захотите держать несколько поколений кэшей в памяти. Например, при обновлении старое поколение данных не подчистится, если есть активные читатели, и будет находиться в памяти, пока не подоспеет новое (третье) поколение и не будет вызван retire() на втором поколении. Затраты по памяти ×3 — нехорошо.

Как раз для таких случаев в C++26 и добавили RCU, предоставляющий полный контроль над данными. Его использование очень похоже на Hazard Pointer:

struct Data   : std::rcu_obj_base<Data> { /* members */ };  std::atomic<Data*> pdata_;  template <typename Func> void reader_op(Func userFn) {   std::scoped_lock _{             std::rcu_default_domain()};   Data* p = pdata_;   userFn(p); }  void writer(Data* newdata) {   Data* old = pdata_.exchange(newdata);   old->retire(); } 

struct Data   : std::hazard_pointer_obj_base<Data> { /* members */ };  std::atomic<Data*> pdata_;  template <typename Func> void reader_op(Func userFn) {   auto h = std::make_hazard_pointer();    Data* p = h.protect(pdata_);   userFn(p); }  void writer(Data* newdata) {   Data* old = pdata_.exchange(newdata);   old->retire(); } 

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

Однако с RCU мы получаем ещё и возможность подождать завершения текущего поколения данных и можем явно позвать деструкторы устаревших объектов:

void shutdown() {     writer(nullptr);     std::rcu_synchronize(); // подождать конца поколения     std::rcu_barrier(); // удалить retired объекты } 

Также здесь предусмотрен ручной механизм управления памятью, при котором не надо наследовать свои данные от std::rcu_obj_base:

struct Data { /* members */ };  std::atomic<Data*> pdata_;  template <typename Func> void reader_op(Func userFn) {     std::scoped_lock l(std::rcu_default_domain());     Data* p = pdata_;     if (p) userFn(p); }  void writer(Data* newdata) {     Data* old = pdata_.exchange(newdata);     std::rcu_synchronize(); // дождаться завершения старых читателей     delete old; }  void shutdown() {     writer(nullptr); } 

Наконец, за счёт того что RCU не требуется знание о защищаемых объектах, можно защищать одновременно несколько объектов:

struct Data { /* members */ }; struct Data2 { /* members */ };  std::atomic<Data*> pdata_; std::atomic<Data2*> pdata2_{getData2()};  template <typename Func> void reader_op(Func userFn) {     std::scoped_lock l(std::rcu_default_domain());     userFn(pdata1_.load(), pdata2_.load()); } 

Это очень удобно, если вы разрабатываете lock-free или wait-free алгоритмы. Вы можете сделать свой маленький Garbage Collector и отделить задачу написания алгоритма от задачи менеджмента памяти.

native_handle()

С++26 теперь предоставляет доступ к файловому дескриптору (handle) для std::*fstream классов. Появляется возможность вызывать специфичные для платформы методы и при этом продолжать использовать классы стандартной библиотеки:

std::ofstream ofs{"data.txt"}; ofs << "Hello word!"; ofs.flush();  // передать из внутренних буферов данные в систему flush(ofs.native_handle());  // дождаться записи на диск 

*function*

Начиная с C++11, в стандартной библиотеке есть класс std::function, который позволяет скрыть информацию о типе функционального объекта, копирует сам функциональный объект и владеет им. Весьма полезный механизм, но со временем пришло понимание, что можно сделать лучше.

Возьмём, к примеру, std::function:

• Он требует копируемости объекта. Но в современном коде функциональные объекты могут быть не копируемыми, а лишь перемещаемыми (или даже неперемещаемыми).
• Не работает с noexcept. Зачастую хочется указать в интерфейсе, что функциональный объект не должен бросать исключения (например, std::function<int(char) noexcept>.
• Не передаётся в регистрах. Тип нетривиален, из-за чего многие платформы не могут его передавать в функции максимально эффективно.
• У него сломан const. Можно сохранить в std::function функциональный объект с состоянием, которое будет меняться при вызове. При этом всё ещё можно звать std::function::operator().

Чтобы побороть эти проблемы, в C++23 и C++26 были добавлены новые классы:

• std::move_only_function — C++23 владеющий класс, который работает с const +noexcept и позволяет принимать во владение некопируемые объекты.
• std::copyable_function — C++26 владеющий класс, который работает с const +noexcept. Фактически это исправленный и осовремененный std::function.
• std::function_ref — C++26 невладеющий класс, который работает с const + noexcept. Максимально эффективно передаётся компилятором через параметры функций. Фактически это type-erased ссылка на функцию.

Со всеми этими новинками намного проще выражать требования к функциональным объектам прямо в коде:

// Ссылка на функциональный объект, который не должен менять своё состояние и // не должен выкидывать исключения std::string ReadUntilConcurrent(std::function_ref<bool(int) const noexcept> pred);  // Владеющий функциональный объект, который может менять своё состояние и // не должен выкидывать исключения std::string AsyncReadUntil(std::move_only_function<bool(int) noexcept> pred);  // Владеющий функциональный объект, который не должен менять своё состояние и // может копироваться внутри метода AsyncConcurrentReadUntil std::string AsyncConcurrentReadUntil(std::copyable_function<bool(int) const> pred); 

constexpr

Хорошие новости для всех поклонников compile time вычислений. В C++26 больше математических функций из <cmath> и <complex> были помечены как constexpr.

Также разрешили делать static_cast указателя к void* и преобразование из void* к указателю на тип данных, который действительно находится по данному указателю. С помощью этих нововведений можно написать std::any, std::function_ref, std::move_only_function, std::copyable_function и другие type-erased классы, которыми можно пользоваться в compile time.

А ещё функции std::*stable_sort, std::*stable_partition и std::*inplace_merge тоже стали constexpr.

std::submdspan

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

std::vector<short> image = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18}; // R G B,R G B,R G B, R G B, R G B, R G B enum Colors: unsigned { kRed, kGreen, kBlue, kTotalColors }; 

Начиная с C++23, есть класс std::mdspan. Он позволяет представить единый кусок памяти в виде многомерного массива. Например, массива с размерностями 2 x 3 x kTotalColors:

auto int_2d_rgb = std::mdspan(image.data(), 2, 3, (int)kTotalColors); 

С его помощью можно вывести все зелёные составляющие пикселя с помощью подобного кода:

std::cout << "\nGreens by row:\n"; for(size_t row = 0; row != int_2d_rgb.extent(0); row++) {   for(size_t column = 0; column != int_2d_rgb.extent(1); column++)     std::cout << int_2d_rgb[row, column, (int)kGreen] << ' ';   std::cout << "\n"; } 

Вывод будет такой:

Greens by row: 2 5 8 11 14 17 

А вот дальше — новинка C++26. Можно создавать вью над отдельными размерностями массива. Например, вью над строкой с индексом 1 по зелёным пикселям:

auto greens_of_row0 = std::submdspan(int_2d_rgb, 1, std::full_extent, (int)kGreen); 

Воспользуемся ей:

std::cout << "Greens of row 1:\n"; for(size_t column = 0; column != greens_of_row0.extent(0); column++)   std::cout << greens_of_row0[column] << ' '; 

Получим:

Greens of row 1: 11 14 17 

Другой пример. Вью над всеми зелёными пикселями:

std::cout << "\nAll greens:\n"; auto pixels = std::mdspan(int_2d_rgb.data_handle(), int_2d_rgb.extent(0) * int_2d_rgb.extent(1), (int)kTotalColors); auto all_greens = std::submdspan(pixels, std::full_extent, std::integral_constant<int, (int)kGreen>{}); for(size_t i = 0; i != all_greens.extent(0); i++)   std::cout << all_greens[i] << ' ';  

Вывод такой:

All greens: 2 5 8 11 14 17 

Прочие новинки

Чтобы проще было работать с std::to_chars и std::from_chars, в структуру результата этих функций добавили explicit operator bool(). Теперь можно писать if (!std::to_chars(begin, end, number)) throw std::runtime_error();.

std::format научился выводить адреса указателей, а заодно диагностировать больше проблем с форматом строки на этапе компиляции.

Для различных типов std::chrono были добавлены функции хэширования, чтобы можно было легко их использовать в unordered-контейнерах.

Кстати о контейнерах. Была добавлена последняя пачка недостающих перегрузок для работы с гетерогенными ключами. Теперь все методы at, operator[], try_emplace, insert_or_assign, insert, bucket не требуют временных копий ключей при использовании с ключами другого типа.

std::bind_front и std::bind_back обзавелись возможностью принимать member-pointer шаблонным параметром, что уменьшает размер итогового функционального объекта, и позволяет ему лучше попадать в преаллоцированные буферы и регистры. Пустячок, а приятно.

Дальнейшие планы

Международный комитет активно взялся за std::simd и executors. Есть все шансы увидеть последний в течение года в стандарте.

Наша Рабочая Группа 21 потихоньку начала расширяться. К нам присоединились Роман Русяев и Тимур Думлер. Надеемся, что работа над идеями и прототипами ускорится.

Следующая встреча международного комитета будет в ноябре. Если вы нашли какие-то недочёты в стандарте или у вас есть идеи по улучшению языка C++ — пишите. Поможем советом и делом.