Хабрахабр

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

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

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

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

std::atomic<int> a; и std::atomic<int> 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 int c;
}; std::vector<C> v = {C{1}};
v.pop_back();
v.push_back(C{2});
assert(v.back().c == 2); // ]:->

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

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

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

*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 <type_traits> template <typename... Xs>
auto f (Xs...) -> std::invoke_result_t<Xs...>;

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

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

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

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

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

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

Numbers TS

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

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

Executors

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

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

template <std::input_range Range>
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), превращать в них каждый алгоритм.

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть