В этот раз без внимания не остались темы:

• Рефлексия времени компиляции и оператор «монобровь»
• Constexpr, много constexpr
• SIMD
• Structured bindings as a pack
• Безопасность, контракты, libc++ hardening, профили, UB и std::launder
• Сколько бит в байте?

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

Reflection, а именно предложение P2996, на полном ходу движется к принятию в C++26.

Сейчас есть как минимум три имплементации. Одна из них открытая. Некоторые из имплементаций доступны на https://godbolt.org/ (вот только там подустаревшие прототипы, так что современные примеры пока не собираются).

Интересный момент: текущее предложение по рефлексии не позволяет работать с атрибутами. Об этом сожалели многие разработчики (в том числе и на Хабре), так как это мешает навешивать произвольные данные на типы и поля… UPD: Не смотря на то, что рефлексия позволяет работать с алиасами, получить их из типа не получится:

template <class T, auto name> using JsonField = T;  JsonField<std::string, "user-name"> name{};  static_assert(  // увы, не сработает :(     // `type_of` отбрасывает информацию об алиасе     [: template_arguments_of(type_of(^^name))[1] :]     == std::string_view{"user-name"});  // Убираем алиас-информацию static_assert(dealias(type_of(^^name)) == ^^std::string); 

И да, было решено превратить оператор для рефлексии ^ в ^^ (без пробела между символами). С лёгкой руки некоторых участников оператор назвали unibrow — «монобровь».

P2996 всю неделю варился в подгруппах LWG и CWG и там наблюдался весьма неплохой прогресс, но в черновик стандарта его пока ещё не вмерджили. При этом многие вещи, необходимые для рефлексии, были вынесены в отдельные constexpr-предложения — и их-то как раз приняли.

constexpr

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

constexpr int foo(int x) {     // Невалидная дата передана в constexpr-конструктор. Конструктор теперь      // отработает на этапе компиляции, будет выброшено исключение,     // которое никто не перехватывает... Компиляция прервётся.     const Date date{"1900-23-01"};       return date.days() + x; } 

Атомарные типы atomic<T> и atomic_ref<T> тоже стали constexpr в P3309. Теперь, например, можно писать многопоточный generic-код, и выполнять его в один поток во время компиляции:

constexpr bool process_first_unprocessed(std::atomic<size_t> & counter,                                          std::span<cell> subject) { const size_t current = counter.fetch_add(1);   if (current >= subject.size()) { return false; }  process(subject[current]); return true; }  constexpr void process_all(std::span<cell> subject, unsigned thread_count = 1) { // ОК выполнить в compile time, если thread_count == 1 std::atomic<size_t> counter{0}; auto threads = std::vector<std::jthread>{};  assert(thread_count >= 1);  for (unsigned i = 1; i < thread_count; ++i) { threads.emplace_back([&]{ while (process_first_unprocessed(counter, subject)); }); }  while (process_first_unprocessed(counter, subject)); }

Structured bindings также стало возможно хранить как constexpr-переменные благодаря P2686. Теперь constexpr static auto [v0, v1] = A{2, 3}; скомпилируется.

Алгоритмы тоже не остались без внимания: в P3508 и P3369 обросли constexpr алгоритмы std::uninitialized_* и std::ranges::uninitialized_*. Теперь писать свои constexpr-алгоритмы стало ещё проще!

SIMD

В черновик стандарта C++26 приняли SIMD P1928. Другими словами, появилась возможность векторизировать обработку данных в платформонезависимом виде:

void sinuses(std::span<float> data) {     using floatv = std::simd<float>;     auto it = data.begin();     for (; it <= data.end() - floatv::size(); it += floatv::size()) {         // Прочитает сразу floatv::size() чисел, допустим 8         floatv vec(it);          // Сразу для 8 чисел посчитает синус и запишет результат обратно в data         std::sin(vec).copy_to(it);     }     for (; it < data.end(); ++it) {         *it = std::sin(*it);     } } 

В зависимости от того, под какой процессор скомпилировано ваше приложение, результат floatv::size() будет отличаться. Если архитектура поддерживает эффективную работу с 8 float одновременно, то будет 8. Если соберёте приложение под совершенно другую архитектуру (даже не x86), то floatv::size() выдаст значение именно под эту архитектуру (*).

* Если вы разрабатываетесь под архитектуру RISC-V, возможны нюансы. Пожалуйста, посмотрите насколько std::simd хорошо ложится на вашу архитектуру, и напишите свои мысли в комментах (или мне в личку).

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

void sinuses(std::span<float> data) {     std::for_each(std::execution::simd, data.begin(), data.end(), [](auto& v) {         v = std::sin(v);     }); } 

Ах да, std::simd тоже помечен как constexpr и им можно пользоваться в compile time.

Structured bindings as a pack

Хорошая новость! В C++26 можно будет не пользоваться Boost.PFR для поиндексного обращения к элементам, так как эта функциональность библиотеки будет доступна прямо в ядре языка C++. Благодаря P1061 можно раскладывать кортежи и агрегаты произвольных размеров на отдельные поля, а вместе с принятым ранее P2662 удобно к ним обращаться:

[](const auto& some_struct) {     auto [...x] = some_struct;     static_assert(sizeof...(x) < 3, "Too many fields");     if constexpr (sizeof...(x) == 2) {         foo(x...[1], x...[0]);     } else {         foo(x...);     } } 

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

Прочие нововведения C++26 с последней встречи

Добавились типы std::indirect<T> и std::polymorphic<T> P3019. Первый предназначен для хранения объекта по указателю. При этом его копирование приводит к копированию объекта, на который он ссылается. Полезная штука для создания рекурсивных структур и вынесения больших подобъектов в динамическую память, чтобы сам объект мог умещаться на стеке. std::polymorphic<T> работает аналогично, но позволяет хранить в себе наследников от T, обеспечивая их правильное копирование.

Предложение P3138 добавило std::views::cache_latest, для кеширования подсчитанных значений. Это позволяет для transform(f) | filter(g) кешировать результат трансформации, и не звать f дважды для каждого успешно прошедшего фильтрацию значения.

Ещё приземлилось множество оптимизаций для линейной алгебры и работы с многомерными спанами в P2897, P3222, P3050, P3355.

А также как всегда множество небольших багфиксов описаний в черновике стандарта — как для стандартной библиотеки, так и для ядра языка.

Безопасность

Безопасность — очень широкий термин. Многие в него вкладывают разный смысл: безопасная работа с памятью, отсутствие уязвимостей, отсутствие переполнений, отсутствие нарушений инвариантов в коде, автоматическое отслеживание времени жизни, отсутствие UB и т. п. Как ни печально, полностью валидировать правильную работу приложения в автоматическом режиме просто невозможно:

bool TriggerAirbag(control& c) noexcept {     return c.car_is_moving() || c.car_is_hit();  // ошибка } 

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

В комитете идёт активная работа по улучшению различных аспектов безопасности языка.

Первое предложение, которое уже длительное время обсуждается в комитете — контракты P2900. Это возможность показывать инварианты вашего кода компилятору, чтобы он мог проверять время компиляции и время рантайма. Контракты подразумевают ручное проставление:

float sqrt(const float x)     pre(x >= 0); 

Компилятор сможет обнаружить нарушение контракта на этапе компиляции для вызова sqrt(-1.0) и выдать диагностику. Для случаев, когда переменную x нельзя вывести на этапе компиляции, можно заставить компилятор добавлять рантайм проверку и вызывать contract_violation_handler.

И казалось бы, что подобные рантайм-проверки во всех частях кода должны вести к замедлению программы и пользоваться ими в продакшене невозможно. Но тут неожиданно появляется libc++ hardening. Проставление подобных проверок для стандартной библиотеки C++ привело к замедлению на 0,3% (приложение становится медленнее на 1/333), и при этом позволило обнаружить проблемы, которые не отлавливали статические анализаторы и санитайзеры. Разработчики компиляторов поработали на славу, добавив множество оптимизаций, чтобы проверки были легковеснее и оптимизировались лучше.

Hardening очень понравился комитету: есть высокий шанс, что P3471 попадёт в C++26 и появится hardened-режим работы стандартной библиотеки и он будет завязан на предложение по контрактам.

Отдельное предложение по улучшению безопасности кода на C++ — предложение по введению в язык профилей P3081. Профили — это одновременно и встроенный в компилятор статический анализатор для предотвращения использования опасных конструкций (например, const_cast, аллокаций через new) и одновременно режимы для кодогенерации более надёжного кода с рантайм-проверками (например, на nullptr-разадресацию). На мой взгляд, самые слабые части этого предложения — отсутствие детального описания и отсутствие прототипа.

Есть ещё идеи по анализу времени жизни объектов на этапе компиляции, но они очень далеки от внедрения — в C++26 мы их точно не увидим.

По-прежнему идёт работа по старым направлениям. Продолжается борьба с undefined behavior (UB) в разных частях стандарта. Так, наше предложение от Рабочей Группы 21 по уничтожению UB при работе с placement new P3006 прошло обсуждение в EWG и есть все шансы увидеть его C++26. Для нас это предложение особо важно, так как позволяет зафиксировать текущее поведение компиляторов, например, в проекте 🐙 userver, где из-за различных их ограничений нет возможности использовать std::launder (который ни одному из компиляторов и не нужен в этом месте!).

Сколько бит в байте?

Казалось бы, простой вопрос, но есть нюанс…

В предложении P3477 идёт работа над тем, чтобы зафиксировать в C++, что в байте именно 8 бит. Это немного упростит стандарт языка и позволит разработчикам не пользоваться CHAR_BIT.

Итоги

C++26 уже не за горами. До feature freese остаётся всего четыре встречи комитета: сейчас уже закрывается дверь для новых предложений, одновременно затрагивающих стандартную библиотеку и ядро языка.

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

Если у вас есть важные замечания к стандарту, пожалуйста, делитесь ими на https://stdcpp.ru. А если хотите пообщаться по поводу placement new в userver, приходите на ночь опенсорс-библиотек, будет весело!