Баги C++20. Итоги встречи в городе Белфаст

?v=1

На днях прошла встреча комитета по стандартизации языка программирования C++ в городе Белфасте. От представителей стран в комитет прилетело около 400 замечаний к C++20, с половиной из них успели расправиться.

Под катом вас ждут результаты обсуждений замечаний России (да-да, ВАШИХ замечаний к C++20), некоторые замечания других стран, ну и подходящие новинки C++23 (Executors!).

Все те проблемы с C++, о которых люди упоминали на сайте stdcpp.ru, в чате @ProCxx или лично на конференциях, мы оформили в виде замечаний к C++20. И вот что из этого вышло…

std: atomic a{}; и std: atomic b;


Может показаться странным, но переменные a и b не инициализируются 0. Чтобы проинициализировать атомарную переменную нулём, надо было писать именно std: atomic с{0};

Такое поведение совершенно не-очевидно, и многие разработчики обжигались. Комитет принял наше замечание к стандарту, и в C++20 конструкторы по умолчанию для std: atomic_flag и std: atomic будут инициализировать переменные в clear state и T () соответственно.

std: launder


Начиная с C++17 в стандарте есть страшная функция std: launder. Люди из комитета думали, что разработчики стандартных библиотек и обычные пользователи разберутся, как с ней быть.

На практике же оказалось, что в ряде случаев этой функцией невозможно воспользоваться. Крайне не очевидно, что она в принципе нужна:

struct C {
    const in c;
};

std::vector v = {C{1}};
v.pop_back();
v.push_back(C{2});
assert(v.back().c == 2); //  ]:->

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

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

Так что начиная с C++20 вы можете спокойно хранить структуры со ссылками и константными полями в std: optional, std: variant, std: vector, std: deque и пр. Теперь placement new автоматически применяет часть логики std: launder.

*this в конструкторах


Это одно из замечаний, где нас ждал провал:

struct C {
    C(C&& other) noexcept
      : initial_(other.initial_)
      , secondary_(other.initial_) // O_O
    {}

    int initial_;
    int secondary_;
};

Согласно текущим правилам, в строчке с O_O компилятор вправе считать, что &other == this и, соответственно, одной строчкой выше мы переписали значение other.initial_ и его надо перечитать.

Другими словами, компилятор вправе считать, что ещё не созданный класс алиасится с параметром, от которого объект конструируется, и из-за этого может генерировать неоптимальный код.

Некоторые компиляторы (например, GCC), считают, что пользователи такое безобразие не пишут, и полагают, что алиасинг не возможен.

Наше замечание «Давайте считать, что алиасинг невозможен» комитет отклонил. Как выяснилось, в некоторых кодовых базах есть страшные хаки, где &other == this, и люди пока не готовы с ними распрощаться.

operator<=> и embedded-программирование


Чтобы работал spaceship operator, вам нужен заголовочный файл. Однако его было в списке заголовочных файлов, которые доступны на любых платформах (в том числе платформах без оперативной памяти).

Теперь он в списке:)

Остальное


По другим нашим замечаниям был вынесен вердикт «Не в C++20»:
* Мы хотели, чтобы __func__ можно было использовать в constexpr.
* Мы хотели, чтобы в концептах нельзя было использовать incomplete type, потому что иначе вы получаете множественные нарушения ODR. Но у замечания был неожиданный положительный эффект: компиляторы теперь выдают предупреждение, если вы используете incomplete type в requires.
* Мы хотели поправить оператор присвоения для std: string, чтобы не происходило подобное безобразие:

basic_string::operator=(charT c):
double d = 3.14;
std::string s;
s = d; // Compiles


Комитет предложил написать отдельную бумагу и поправить это уже после C++20.
* Мы хотели убить присвоение временных строк в std: string_view:

std::string foo();

std::string_view sv;
sv = foo(); // Compiles... dangling reference 


Исход тот же, что у предыдущего замечания: комитет предложил написать отдельную бумагу и поправить это уже после C++20.
* Мы запросили, чтобы следующий код компилировался:

#include 

template 
auto f (Xs...)
    -> std::invoke_result_t;


Нам ответили, что всё сложно, починить к C++20 практически нет шансов.

Замечания других стран


Из значительных изменений: добавление конструкторов для std: span от типов, удовлетворяющих концепту ranges: contiguous_range. Так что теперь span сможет неявно создаваться от std: vector и std: string. Ещё добавили конструктор std: string_view от двух итераторов, удовлетворяющих концепту ranges: contiguous_iterator.

Занятные правки ожидали . За последние три года operator<=> сильно изменился. Он теперь не участвует в сравнениях на равенство, и, соответственно, треть содержимого больше не нужна. Несколько стран это заметили — стандарт подсократили.

Прекрасное изменение прокралось в non-type template parameters. В C++20 можно будет передавать в качестве шаблонного параметра практически любые классы (см. P1907) с constexpr деструктором и публичными членами, даже если в классе содержатся floating-point типы или ссылки.

Так же добавили недостающие const в разные части стандарта, изменили имена и порядок аргументов некоторых новых для C++20 функций. Ещё появились множественные правки для концептов и ranges, сокращения текста стандарта и прочие мелочи.

Numbers TS


Мы с ZaMaZaN4iK смогли расшевелить комитет документом «C++ Numerics Work In Progress». Теперь появились наполеоновские планы к C++23 выдать пользователям набор новых типов чисел (wide_integer, integer, rational), вместе со вспомогательными низкоуровневыми методами для работы с переполнениями и удобными алиасами.

Мне сказали приготовить к следующему заседанию выступление с введением в идеи для всего комитета.

Executors


Executors — один из приоритетов C++23. Они необходимы для реактивного программирования, для асинхронного программирования (сеть, диск, процессы…), являются основой для шедулинга корутин и должны предоставлять единый интерфейс для сторонних библиотек.

При этом, executors должны оптимизировать алгоритмы под свою внутреннюю имплементацию. Например, для кода:

template 
void MySort(Range& data) {
    namespace stdr = std::ranges;
    std::sort(GetGlobalExecutor(), stdr::begin(data), stdr::end(data), 42);
}


функция GetGlobalExecutor () может вернуть:
* однопоточный executor — он должен выполнить обычный std: sort на своём потоке;
* многопоточный executor — он должен произвести паралельную сортировку;
* GPU executor — он должен переместить данные в память видеокарты, произвести сортировку там и вернуть данные обратно;
* NUMA executor —…
*…

Пока что для реализации подобной функциональности нужно делать страшные Customization Point Objects (CPO), превращать в них каждый алгоритм. Комитету это не понравилось…

Но по крайней мере предварительно одобрили P0443 — базовый интерфейс. Все последующие предложения для executors надо будет писать в виде патчей к P0443.

Вместо итогов


Теперь от C++20 нас отделяет всего одна встреча комитета. Осталось совсем чуть-чуть…

Ну, а все желающие пообщаться с представителями комитета в живую — заглядывайте на митапы и C++ конференции (*):
* Corehard в Минске
* C++ Siberia 2020
* C++ Russia 2020
* St. Petersburg C++ User Group
* C++ Meetup 2019 в Москве

(*) Лайфхак: за билет на конференцию не надо платить, если ты докладчик.

© Habrahabr.ru