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

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

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

13.11.2019 08:16

antoshkka 41 8100 Источник

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

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

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

std::atomic<int> a{}; и std::atomic<int> b;

Может показаться странным, но переменные a и b не инициализируются 0. Чтобы проинициализировать атомарную переменную нулём, надо было писать именно std::atomic<int> с{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 может проходить или проваливаться.

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

Так что начиная с 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, вам нужен заголовочный файл <compare>. Однако его не было в списке заголовочных файлов, которые доступны на любых платформах (на так называемых freestanding имплементациях стандартной библиотеки, которые можно использовать на любом утюге).

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

Остальное

По другим нашим замечаниям был вынесен вердикт «Не в 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.

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

Прекрасное изменение прокралось в 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 <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), превращать в них каждый алгоритм. Комитету это не понравилось…

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

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

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

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

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

Комментарии (41)

ZaMaZaN4iK
13.11.2019 11:36
#20880756
Наиболее полный список того, что было сделано на данном заседании можно прочитать тут

ncr
13.11.2019 11:46
#20880812
* Мы хотели убить присвоение временных строк в std::string_view:
```
std::string foo();

std::string_view sv;
sv = foo(); // Compiles... dangling reference
```
А заодно вы хотели убить и
```
std::string foo();
void bar(std::string_view sv);

bar(foo()); // perfectly fine
```
?
Или как предлагалось это различать?
1. antoshkka Автор
  13.11.2019 11:49
  #20880836
  Первый пример — вызов assignment operator
  Второй пример — вызов конструктора. Второе трогать не предлагали, только присвоения должны были попасть под static_assert
  1. gridem
    13.11.2019 20:18
    #20883286
    +2
    Т.е. если я напишу:
    
    std::string foo(); std::string_view sv = foo();
    
    То это будет компилироваться даже с учетом правок? Несимметрично как-то.
    
    antoshkka Автор
    13.11.2019 20:38
    #20883358
    Да, увы, даже с правками соберётся.
    
    Вся надежда на -Wlifetime godbolt.org/z/U_eG-H
    
    khim
    14.11.2019 04:56
    #20884310
    А то, что если заменить std::string_view, то эти две операции обе валидны, но даже и близко не похожи по смыслу — вас не смущает?
    
    Да, тот факт, что в C++ иницилизация переменной может быть похожа на присваивание — это неприятный эффект, но если вы их не умеете различать, то программировать на C++ просто не стоит…

ncr
13.11.2019 12:30
#20881034
Ясно, спасибо.
Однако, разделение declaration и assignment — в общем случае, дурной тон (в решарпере вроде даже диагностика есть), т.е. в реальном мире там скорее всего будет std::string_view sv = foo(); и dangling reference никуда не денется.
1. antoshkka Автор
  13.11.2019 13:10
  #20881248
  Верно, но увы, этого джина выпустили ещё в начале 90х и до сих пор не могут загнать в бутылку. Concepts из стандарта пытаются требовать чтобы присваивание и конструирование вели себя одинаково. Но язык всё ещё позволяет делать их разными.
  
  В данном конкретном случае выбор между консистентностью или безопасностью :(
  1. Videoman
    13.11.2019 17:25
    #20882618
    Ох, а как они этого добьются. Чего только стоят разные правила вывода типов при конструировании:
    
    A a; //... // Direct initialization: B b(a); // Одни правила перегрузки // Copy initialization: B b = a; // Другие правила перегрузки
    
    При присваивании третьи правила.
    А сколько мне головной боли из-за этого доставили библиотечные std::optional и std::tuple, из-за того что у них есть перегрузки для универсальных ссылок любого типа — U&&. Эти перегрузки настолько «жадные» что хватают практически все что не попадя, не давая никак исправить это поведение. Если в коде есть классы-врапперы которые сами могут преобразовываться к разным типам, работа с конструирование std::optional и std::tuple превращается в головную боль.
    Видимо только на концепты и осталась надежда.
    
    antoshkka Автор
    13.11.2019 17:46
    #20882708
    +1
    В комитете любят шутить «We are consistently inconsistent»
    
    Videoman
    13.11.2019 18:18
    #20882852
    +1
    Да они там шутники — теперь многое становится понятно :). Добавили — убрали, добавили — убрали…
1. Overlordff
  13.11.2019 13:11
  #20881254
  Всё ещё можно переприсваивать.

sborisov
13.11.2019 13:11
#20881260
+1
Интересно, возьмут ли что-то из новых плюсов в Си(20,23)?
Хотя Линус даже _Bool до сих пор не очень жалует.
lkml.org/lkml/2013/8/31/138
1. ZaMaZaN4iK
  13.11.2019 13:39
  #20881416
  Можете последить за активностью комитета по Си :) Скажем так — он скорее мертв, чем жив (но что-то там делают). Хорошо это или плохо — каждый пусть сам решает.
1. antoshkka Автор
  13.11.2019 14:26
  #20881692
  В C хотят взять C++ синтаксис для атрибутов (например [[likely]] ), wide_int, throws (который std::expected на уровне компилятора). За остальными новинками я особо не смотрел, но удивлюсь если у C комитета нет планов на Юникод и to_chars/from_chars

Overlordff
13.11.2019 13:15
#20881276
+1
В ТГ чате упоминалось, что США выдвинуло замечание на фикс ключевых слов в корутинах (предложение Антона, которое не прошло ранее). Я так понимаю, успехов они не добились?
1. antoshkka Автор
  13.11.2019 14:19
  #20881638
  Решили что «лучше страшненькие корутины сейчас, чем страшненькие корутины потом». Улучшать можно бесконечно, когда-то надо и релизить. ~10 лет — достаточный срок для тестирвания и разработки.
1. MooNDeaR
  13.11.2019 14:24
  #20881674
  yield — это доходность облигаций и введение такого ключевого слова сломает тонны финансового софта.
  1. antoshkka Автор
    13.11.2019 14:29
    #20881708
    В предложении yield контекстно зависимый, потому старый код для работы с финансами и для подсчета урожая кукурузы не сломается

Amomum
13.11.2019 13:24
#20881338
+1
Такой общий вопрос к работе комитета. Недавно хотел я выяснить статус одного предложения. Я знаю номер предложения, я знаю ссылку на open-std. Но как понять, было ли оно принято или отклонено?

Судя по всему, чуть ли не единственный способ сейчас — спросить в "официальном" слаке. Ну или долго-долго листать все результаты всех встреч и искать там упоминания этого предложения, молясь, чтобы оно было там упомянуто с номером, а не просто как "Numbers TS".

Может быть, есть смысл завести хотя бы какую-нибудь табличку со статусами предложаний? Или может быть она уже есть, просто я не смог ее найти?
1. ZaMaZaN4iK
  13.11.2019 13:27
  #20881360
  +1
  Теперь можно смотреть вот здесь — github.com/cplusplus/papers/issues
  
  Историю о более старых бумагах поднять не получится, скорее всего.
  1. Amomum
    13.11.2019 13:30
    #20881378
    Ооо, круто! Спасибо!
  1. antoshkka Автор
    13.11.2019 13:35
    #20881392
    По более старым бумагам я могу давать информацию или любой другой человек из комитета. + могу выдавать стенограмы обсуждений отдельных бумаг, если вы работаете над смежной темой.
    
    ZaMaZaN4iK
    13.11.2019 13:36
    #20881402
    Очень интересно, как к выдаче стенограмм относятся в ISO :)
    
    antoshkka Автор
    13.11.2019 14:20
    #20881644
    Они для того и пишутся, чтобы их кто-то читал )

kachsheev
13.11.2019 14:00
#20881526
+1
Антон, спасибо огромное за статью!

Вопрос по Numerics. Есть ли планы по имплементации чисел с плавающей запятой? Таким образом можно было бы double/float перевести в constexpr и consteval контексты.
1. ZaMaZaN4iK
  13.11.2019 14:07
  #20881568
  Есть вот такое — www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1438r1.html
  
  Но в таком виде оно не пройдет, потому что слишком много замечаний по нему будет. Его надо сильно доделывать.
1. antoshkka Автор
  13.11.2019 14:22
  #20881664
  float/double уже можно использовать в constexpr и consteval. Их даже шаблонными non type параметрами можно использовать в C++20.
  
  А вообще есть планы на unbounded float и разновидности decimal. Успеют ли они воплотиться в будущем Numbers TS — увидим

EkvVN
13.11.2019 17:03
#20882530
+1
А как быстро в компиляторах успевают реализовывать все эти нововведения, которые появляются в новых стандартах C++?
1. antoshkka Автор
  13.11.2019 17:08
  #20882554
  Почти все языковые новинки C++20 уже обкатаны и есть в компиляторах. Только вот разные новинки — в разных компиляторах.

kdmitrii
13.11.2019 19:17
#20883072
+6
Мне вот любопытно, если как утверждается в комитете сидит куча людей из "высокой производительности" то почему:
- STL потоки ввода вывода настолько медленные, что за 5 минут написанная буфферезирующая реализация на функциях типа read/write работает в несколько раз быстрее?
- Регулярные выражения работают неадекватно долго, там нет прекомпиляции или что?
- В STL нет lock-free алгоритмов и структур данных? Я вообще не понимаю о какой производительности можно говорить без этой штуки.
- Нет никаких методов работы с интринсиками и прочей векторизацией?
- Нет ни одного (не то что эффиктивного) алгоритма работы с графами/сетями(это всмысле транспортными сетями, а не интернетными)?
- Почему там нет самых быстрых из известных на данный момент алгоритмов сортировки/поиска строк/хеширования и особенно почему нет алгоритмов не общего назначения а узкоспециаллизированных (ну типа радикс сорта)?
- Почему нет никаких методов работы с распределенными системами? Нет балансировки нагрузки и тд?
  Я работал в нескольких компаниях, где производительность была единственным критерием. Так вот там на критическом пути НИКОГДА не используют стандартные функции C++. Вообще C++ используется как нативный метод общения с ОС(для использования NUMA аллокаций например) и вставок ассемблера.
  Можно мне пример реально высокой производительности (желательно по критерию малой задержки) где применяется стандартный C++ на критическом пути (вектрра там, мэпы, cout, to_string, да что угодно рантаймовое).
1. antoshkka Автор
  13.11.2019 20:03
  #20883240
  +2
  1) Странно, вроде бы они не настолько медленные. Флаг std::ios_base::binary не помогал? В комитете недавно началась работа над async файловым вводом/выводом, к C++26 возможно сойдётся.
  2) Это известная проблема, сейчас думают втащить github.com/hanickadot/compile-time-regular-expressions чтобы её починить
  3) На подходе lock-free queue
  4) Есть в Parallelism TS, SIMD будет уже в C++23
  5) Начали обсуждать, когда будет готово — не известно
  6) Потому что они медленнее std::sort. Если это не так — говорите, сделаем PR в стандартные библиотеки
  7) Никто не предлагал. Как говорит Юсутис «Это ваша вина!< вы не предложили>»
  
  Если вам нельзя аллоцировать в процессе работы, то вы вынуждены использовать freestanding часть стандартной библиотеки. Она именно для этого и для embedded сделана. Вроде бы всё ОК, или я не замечаю какую-то проблему?
  1. izvolov
    14.11.2019 01:22
    #20884118
    Насчёт целочисленных сортировок — есть хорошая, эффективная реализация (у меня в публикациях о ней написано). Существенно быстрее, чем std::sort. Давайте сделаем PR, подскажите как.
    
    antoshkka Автор
    14.11.2019 12:20
    #20885520
    Она динамически аллоцирует, что противоречит требованиям std::sort. Давайте тогда начнём с std::stable_sort для интегральных типов. Попробуйте сделать патч для libc++ github.com/llvm-mirror/libcxx и побенчмаркать
    
    izvolov
    14.11.2019 12:29
    #20885562
    Она динамически аллоцирует
    Ни в коем случае! Динамических аллокаций нет.
    
    Но тут фишка в том, что интерфейс такой сортировки по естественным причинам отличается от интерфейса std::sort и std::stable_sort. В каком виде предлагаете делать патч?
    
    antoshkka Автор
    14.11.2019 12:40
    #20885638
    std::stable_sort аллоцирует буфер под капотом. Можно этот буфер использовать. В случае, если буфер получилось выделить, итераторы random access, и value — интегральный тип — то вызывать вашу сортировку. Так и интерфейс не изменится, и работать будет быстрее.
    
    izvolov
    14.11.2019 12:42
    #20885650
    +1
    Понял. Разумно. Попробую.
    
    А замеры для сравнения самому писать, или есть откуда брать?
    
    antoshkka Автор
    14.11.2019 13:47
    #20886012
    если в libcxx не закомичены — придётся писать свои
1. ZaMaZaN4iK
  14.11.2019 12:03
  #20885430
  Хороший вопрос о том, что стоит ли стандартизировать именно какие-то реализации? или всё же просто реализация STL пусть думает о том, чтобы быть максимально эффективной в общем случае (обычно это так, но в спец. кейсах вы можете найти более эффективное решение).
  
  А так — работы обычно ведутся в этих направлениях. Если есть идеи, что да как должно выглядеть — можете написать предложение, чего именно вы хотите и отправить на рассмотрение в комитет. Рассмотрят точно и накидают комментов. Другой вопрос, что работа это очень сложная и кропотливая… :(

izvolov
14.11.2019 01:13
#20884098
+1
Каков порядок работы с предложениями с сайта stdcpp.ru?
В частности интересует история с invoke_result_t, о которой я писал. Из обсуждения на сайте я сделал вывод, что это никому не интересно, а теперь выясняется, что кто-то таки заинтересовался и пошёл с этим в комитет.
1. antoshkka Автор
  14.11.2019 08:44
  #20884580
  Порядок работы — разгребать по мере сил и возможностей. Если появляются добровольцы — выдаю задания попроще, если нахожу разработчика компилятооов — выдаю хрдкор, остальное — в основном по популярности

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

std::atomic<int> a{}; и std::atomic<int> b;

std::launder

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

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

Остальное

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

Numbers TS

Executors

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

Комментарии (41)

antoshkka Автор

antoshkka Автор

antoshkka Автор

antoshkka Автор

antoshkka Автор

antoshkka Автор

antoshkka Автор

antoshkka Автор

antoshkka Автор

antoshkka Автор

antoshkka Автор

antoshkka Автор

antoshkka Автор

antoshkka Автор

antoshkka Автор

antoshkka Автор