C++29 — начало. Встреча ISO C++ в Брно

Занятно, ваши доводы опровергают многие факты, свидетелем которых я был лично.

А откуда вы черпаете подобную информацию?

C++29 — начало. Встреча ISO C++ в Брно

Именованные параметры в вызовах функций?

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

get/set properties?

Были попытки, большинству C++ разработчиков properties не нравятся

Возможность разрешить перегружать оператор точка?

Автор идеи решил с ней не продолжать - в ней нашлось фундоаментальное логическое противоречие ("Оператор точка должен выполняться перед всеми операциями при любом использовании типа Т с этим оператором. Как передать тип Т в функцию? Оператор точка сработает вначале и изменит тип с Т на что-то другое")

extension methods?

Свободные функции и CPO выполняют ту же роль. Попытки сделать красивый CPO не взлетели, но если у вас есть идеи как это сделать - пожалуйста, расскажите

Да просто возможность задать явно порядок для решения Static Initialization Order Fiasco?

Вообще порядок может выводиться самостоятельно (в теории). Тут не нужен стандарт, тут нужна реализация идеи в компиляторе, чтобы потом её стандартизировать. Попробуйте запрототипировать решение, все будут вам благодарны

C++29 — начало. Встреча ISO C++ в Брно

Тут пошли немного другим путём. Вместо стандартизации одного пакетного менеджера, стандартизуется формат завивсимостей и конфигурирований между пакетниками - Common Package Specification. В результате любая сборочная система сможет потреблять артефакты любого пакетника.

Таким образом получится объединить и проприетарные системы сборки, и не ввязываться в бессмысленный спор "кто станет единым стандартным пакетным менеджером"

C++29 — начало. Встреча ISO C++ в Брно

Сейчас "мячик на стороне" авторов идеи - документ на pattern matching не обновлялся с предпоследней встречи. Собственно по этому на последней встрече эта тема не обсуждалась

Заинтересованных людей много, ставлю на то, что активность скоро возобновится

C++29 — начало. Встреча ISO C++ в Брно

Была попытка успеть втащить его в C++26, но не успели... Теперь неспешно будем втаскивать в C++29

C++29 — начало. Встреча ISO C++ в Брно

Вы правы, IEEE 754 обязывает payload передаваться "An operation that propagates a NaN operand to its result and has a single NaN as an input should produce a NaN with the payload of the input NaN if representable in the destination format."

Он же позволяет игнорировать знак при Nan в подавляющем большинстве операций "For all other operations, this standard does not specify the sign bit of a NaN result".

Ну и стандарт C++ говорит что `is_iec559 == true` значит что для типа выполняется IEEE 754.

Так что больших проблем при защите proposal быть не должно

C++29 — начало. Встреча ISO C++ в Брно

Каноничный способ это std::nan

Если готовы побороться за payload в nan, то с радостью помогу вам. Но вам придётся проработать основные моменты и написать proposal. Подозреваю что там будут трудности, кажется некоторые платформы не позовляют делать -nan, а что у них с payload для nan не представляю.

Но, предлагается унифицированное поведение, которое ухудшает текущее поведение

На самом деле всё хорошо, стандартизировали текущее поведение GCC. Там даже есть достаточно понятные примеры:

constexpr std::float32_t min = std::numeric_limits<std::float32_t>::min();          // OK
constexpr std::float32_t max = std::numeric_limits<std::float32_t>::max();          // OK
constexpr std::float32_t inf = std::numeric_limits<std::float32_t>::infinity();     // OK
constexpr std::float32_t nan = std::numeric_limits<std::float32_t>::quiet_NaN();    // OK

constexpr std::float32_t inf2 = inf * 2;    // OK, also positive infinity
constexpr std::float32_t zero = min / max;  // OK, result cannot be represented, and is rounded to zero
constexpr std::float32_t oflo = max * 2;    // error: non-finite result but operands are finite ([expr.const.core])
constexpr std::float32_t nan2 = nan * 2;    // OK, propagating a NaN
constexpr std::float32_t udef = inf * 0;    // error: result is NaN but neither operand is NaN ([expr.const.core])
constexpr std::float32_t div0 = max / 0;    // error: division by zero is undefined ([expr.mul], [expr.const.core])

То есть всё работает ожидаемо, NaN и Inf можно получать в compile time из numeric_limits, но нельзя "случайно" их создать выражением без NaN/Inf

C++29 — начало. Встреча ISO C++ в Брно

std::format, как минимум под VC, тащит за собой все кишки локалей дат, и одна строка std::format(L"{}", 5) раздувает бинарь на сотни килобайт в релизе

Да, такая же история и с libstdc++ от GCC. Реализации стандартной библиотеки пока помещают всю имплементацию в заголовочный файл, чтобы не думать о ABI и его сломе. Когда реализации устаканятся и дооптимизируются, то они будут внесены в cpp. В новом libstdc++ от GCC даже есть уже нужный макрос сборки, но по умолчанию пока всё в заголовочных файлах

C++29 — начало. Встреча ISO C++ в Брно

<del>

C++29 — начало. Встреча ISO C++ в Брно

почему такой вывод

`"{:L}"` выводит с использованием текущей локали. В примере стоит локаль с разделителем `.` между тысячными. Обычный `"{}"` выводит без использования локалей, и будет просто "120000"

какой у них юзкейс

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

C++29 — начало. Встреча ISO C++ в Брно

Работа над P3294 продолжается, пока непонятно, получится ли увидеть в C++29

C++29 — начало. Встреча ISO C++ в Брно

Какой-то вынос мозга если честно. Почему так?

Так получается более логично, чем в остальных случаях. Смотрите, давайте сделаем классический non virtual interface:

struct Base {
  void call_me(int x) pre(x > 0) { call_me_impl(x); }

private:
  virtual void call_me_impl(int x) = 0;
};

struct Derived {
  void call_me_impl(int x) override pre(x >= 0);
};

Если позвать `derived.call_me_impl(0);`, то всё должно отработать нормально - просто зовётся функция класса, надо на ней проверить `pre(x >= 0)`.
Когда вызов будет происходить через `call_me` базового класса, то надо проверить контракт на `call_me`, а потом контракт `Derived::call_me_impl`

С non virtual interface всё крайне логично. Вот только этот паттерн немного громоздкий (зачастую надо дополнительную функцию писать для каждой виртуальной) и люди его сокращают до:

struct Base {
  virtual void call_me(int x) pre(x > 0) = 0;
};

struct Derived {
  void call_me(int x) override pre(x >= 0);
};

Поведение получаем то же, что и с non virtual interface

C++29 — начало. Встреча ISO C++ в Брно

Для получения Nan и Inf в constexpr можно пользоваться `std::numeric_limits<T>::quiet_NaN()` и `std::numeric_limits<T>::infinity()`. Умножать эти значения на -1 или просто использовать унарный оператор `-` всё ещё можно

А каким образом сейчас вы задаёте payload для NaN?

userver 3.0 — большой релиз фреймворка для IO‑bound‑программ, переход на C++20

о, спасибо большое, будем смотреть и разбираться

userver 3.0 — большой релиз фреймворка для IO‑bound‑программ, переход на C++20

Разные энтузиасты пробовали доьавить поддержку Win, но на этапе сборки как правило застревали :(

Если хотите попробовать - присылайте PR, с радлстью поревьюим и вмержим

userver 3.0 — большой релиз фреймворка для IO‑bound‑программ, переход на C++20

Мы используем yandex-taxi-testsuite для подобных вещей. Это отдельный Python пакет, и он доступен в pip. Он умеет поднимать не только Postgres, но и Redis, Valkey, Mongo... а ещё умеет поднимать ваш сервис, патчить ваши конфиги, делать запросы в ваш сервис и много-много всего другого

Полноценно интегрировать своё приложение с yandex-taxi-testsuite может быть не просто. В качестве примера можно глянуть в userver/testsuite, там как раз лежит всё для бесшовной интеграции приложений на userver. Если нужен только подъем базы от yandex-taxi-testsuite, то всё попроще, и можно посмотеть на userver/postgres тесты в качестве примера

userver 3.0 — большой релиз фреймворка для IO‑bound‑программ, переход на C++20

Мы сейчас во многих местах фреймворка используем Boost.PFR для рефлексии. Как раз пару дней назад был релиз Boost 1.91 и там я добавил экспериментальную поддержку C++26 рефлексии в PFR. Через пол годика можно снимать эксперимент и использовать по умолчанию

Но вот использовать рефлексию C++26 не под ifdef макросами мы не сможем ещё лет 6 - наши пользователи используют C++20

userver 3.0 — большой релиз фреймворка для IO‑bound‑программ, переход на C++20

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

userver 3.0 — большой релиз фреймворка для IO‑bound‑программ, переход на C++20

Мы когда-то проверяли на одной из BSD, и даже апстримили патчи в смежные проекты (кажется gRPC), чтобы сборка работала

Но без настроенного CI и энтузиаста, желающего поддержать платформу, скорее всего сборка немного сломалась.

Кстати, мы ищем добровольцев https://userver.tech/d1/d00/md_en_2userver_2distro__maintainers.html. Не хотите им стать?

С++26 — готов! Итоги встречи ISO C++ в Кройдоне

simd будет в C++26. В GCC-16 уже будет готовая к использованию реализация, а до этого была в GCC реализация std::experimental::simd, на основе которой как раз и принимали std::simd