Как стать автором
Обновить

Комментарии 46

* Мы хотели убить присвоение временных строк в 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
?
Или как предлагалось это различать?
Первый пример — вызов assignment operator
Второй пример — вызов конструктора. Второе трогать не предлагали, только присвоения должны были попасть под static_assert

Т.е. если я напишу:


std::string foo();

std::string_view sv = foo();

То это будет компилироваться даже с учетом правок? Несимметрично как-то.

Да, увы, даже с правками соберётся.

Вся надежда на -Wlifetime godbolt.org/z/U_eG-H
А то, что если заменить std::string_view, то эти две операции обе валидны, но даже и близко не похожи по смыслу — вас не смущает?

Да, тот факт, что в C++ иницилизация переменной может быть похожа на присваивание — это неприятный эффект, но если вы их не умеете различать, то программировать на C++ просто не стоит…
Ясно, спасибо.
Однако, разделение declaration и assignment — в общем случае, дурной тон (в решарпере вроде даже диагностика есть), т.е. в реальном мире там скорее всего будет std::string_view sv = foo(); и dangling reference никуда не денется.
Верно, но увы, этого джина выпустили ещё в начале 90х и до сих пор не могут загнать в бутылку. Concepts из стандарта пытаются требовать чтобы присваивание и конструирование вели себя одинаково. Но язык всё ещё позволяет делать их разными.

В данном конкретном случае выбор между консистентностью или безопасностью :(
Ох, а как они этого добьются. Чего только стоят разные правила вывода типов при конструировании:
A a;
//...
// Direct initialization:
B b(a); // Одни правила перегрузки
// Copy initialization:
B b = a; // Другие правила перегрузки

При присваивании третьи правила.
А сколько мне головной боли из-за этого доставили библиотечные std::optional и std::tuple, из-за того что у них есть перегрузки для универсальных ссылок любого типа — U&&. Эти перегрузки настолько «жадные» что хватают практически все что не попадя, не давая никак исправить это поведение. Если в коде есть классы-врапперы которые сами могут преобразовываться к разным типам, работа с конструирование std::optional и std::tuple превращается в головную боль.
Видимо только на концепты и осталась надежда.
В комитете любят шутить «We are consistently inconsistent»
Да они там шутники — теперь многое становится понятно :). Добавили — убрали, добавили — убрали…
Всё ещё можно переприсваивать.
Можете последить за активностью комитета по Си :) Скажем так — он скорее мертв, чем жив (но что-то там делают). Хорошо это или плохо — каждый пусть сам решает.
В C хотят взять C++ синтаксис для атрибутов (например [[likely]] ), wide_int, throws (который std::expected на уровне компилятора). За остальными новинками я особо не смотрел, но удивлюсь если у C комитета нет планов на Юникод и to_chars/from_chars
В ТГ чате упоминалось, что США выдвинуло замечание на фикс ключевых слов в корутинах (предложение Антона, которое не прошло ранее). Я так понимаю, успехов они не добились?
Решили что «лучше страшненькие корутины сейчас, чем страшненькие корутины потом». Улучшать можно бесконечно, когда-то надо и релизить. ~10 лет — достаточный срок для тестирвания и разработки.

Вроде бы не сильно большое преобразование чтобы оно отложило корутины как таковые? (если мы про co_await -> await говорим). Такую штуку потом уже не сделать. Еще по моему круто что функции явно помечались бы async.

yield — это доходность облигаций и введение такого ключевого слова сломает тонны финансового софта.

В предложении yield контекстно зависимый, потому старый код для работы с финансами и для подсчета урожая кукурузы не сломается
но это не точно

Такой общий вопрос к работе комитета. Недавно хотел я выяснить статус одного предложения. Я знаю номер предложения, я знаю ссылку на open-std. Но как понять, было ли оно принято или отклонено?


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


Может быть, есть смысл завести хотя бы какую-нибудь табличку со статусами предложаний? Или может быть она уже есть, просто я не смог ее найти?

Теперь можно смотреть вот здесь — github.com/cplusplus/papers/issues

Историю о более старых бумагах поднять не получится, скорее всего.

Ооо, круто! Спасибо!

По более старым бумагам я могу давать информацию или любой другой человек из комитета. + могу выдавать стенограмы обсуждений отдельных бумаг, если вы работаете над смежной темой.
Очень интересно, как к выдаче стенограмм относятся в ISO :)
Они для того и пишутся, чтобы их кто-то читал )
Антон, спасибо огромное за статью!

Вопрос по Numerics. Есть ли планы по имплементации чисел с плавающей запятой? Таким образом можно было бы double/float перевести в constexpr и consteval контексты.
Есть вот такое — www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1438r1.html

Но в таком виде оно не пройдет, потому что слишком много замечаний по нему будет. Его надо сильно доделывать.
float/double уже можно использовать в constexpr и consteval. Их даже шаблонными non type параметрами можно использовать в C++20.

А вообще есть планы на unbounded float и разновидности decimal. Успеют ли они воплотиться в будущем Numbers TS — увидим
А как быстро в компиляторах успевают реализовывать все эти нововведения, которые появляются в новых стандартах C++?
Почти все языковые новинки C++20 уже обкатаны и есть в компиляторах. Только вот разные новинки — в разных компиляторах.
НЛО прилетело и опубликовало эту надпись здесь
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 сделана. Вроде бы всё ОК, или я не замечаю какую-то проблему?

Насчёт целочисленных сортировок — есть хорошая, эффективная реализация (у меня в публикациях о ней написано). Существенно быстрее, чем std::sort. Давайте сделаем PR, подскажите как.

Она динамически аллоцирует, что противоречит требованиям std::sort. Давайте тогда начнём с std::stable_sort для интегральных типов. Попробуйте сделать патч для libc++ github.com/llvm-mirror/libcxx и побенчмаркать
Она динамически аллоцирует

Ни в коем случае! Динамических аллокаций нет.


Но тут фишка в том, что интерфейс такой сортировки по естественным причинам отличается от интерфейса std::sort и std::stable_sort. В каком виде предлагаете делать патч?

std::stable_sort аллоцирует буфер под капотом. Можно этот буфер использовать. В случае, если буфер получилось выделить, итераторы random access, и value — интегральный тип — то вызывать вашу сортировку. Так и интерфейс не изменится, и работать будет быстрее.

Понял. Разумно. Попробую.


А замеры для сравнения самому писать, или есть откуда брать?

если в libcxx не закомичены — придётся писать свои
1) Странно, вроде бы они не настолько медленные

это невероятная боль. речь идёт о форматированном вводе-выводе. исследовал как-то реализацию от msvc:
непрерывное блокирующее получение локали и использование printf убивает эффективность напроч
Хороший вопрос о том, что стоит ли стандартизировать именно какие-то реализации? или всё же просто реализация STL пусть думает о том, чтобы быть максимально эффективной в общем случае (обычно это так, но в спец. кейсах вы можете найти более эффективное решение).

А так — работы обычно ведутся в этих направлениях. Если есть идеи, что да как должно выглядеть — можете написать предложение, чего именно вы хотите и отправить на рассмотрение в комитет. Рассмотрят точно и накидают комментов. Другой вопрос, что работа это очень сложная и кропотливая… :(

На мой взгляд, для большей части описанных вами вещей достаточно сделать библиотеки, и нет необходимости менять язык.

kdmitrii
пример реально высокой производительности (желательно по критерию малой задержки) где применяется стандартный C++ на критическом пути (вектрра там, мэпы

Пожалуйста.

kdmitrii
C++ используется как нативный метод общения с ОС(для использования NUMA аллокаций например) и вставок ассемблера.

А по моему опыту, языку C++ не хватает средств для общения с ОС, посмотрите, что с сокетами, например.

И для ассемблеров C++ предназначен не очень, поскольку он сильно на кроссплатформенность ориентирован, а у платформ ассемблеры отличаются. Ассемблерные вставки в C++ вызывают разные неприятности: код достаточно сильно привязывается к комплиятору. Проще уж тогда сразу при сборке вызывать nasm, yasm, fasm (что вам нравится) и не мудрить :) Это у меня, кстати, главное разочарование, связанное с C++, после всех паскалей, где воткнуть пару MMX-инструкций в код можно хоть в делфи, хоть в FPC, даже не особо задумываясь.

Каков порядок работы с предложениями с сайта stdcpp.ru?
В частности интересует история с invoke_result_t, о которой я писал. Из обсуждения на сайте я сделал вывод, что это никому не интересно, а теперь выясняется, что кто-то таки заинтересовался и пошёл с этим в комитет.

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