Комментарии 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
?Или как предлагалось это различать?
Второй пример — вызов конструктора. Второе трогать не предлагали, только присвоения должны были попасть под static_assert
Т.е. если я напишу:
std::string foo();
std::string_view sv = foo();
То это будет компилироваться даже с учетом правок? Несимметрично как-то.
std::string_view
, то эти две операции обе валидны, но даже и близко не похожи по смыслу — вас не смущает?Да, тот факт, что в C++ иницилизация переменной может быть похожа на присваивание — это неприятный эффект, но если вы их не умеете различать, то программировать на C++ просто не стоит…
Однако, разделение declaration и assignment — в общем случае, дурной тон (в решарпере вроде даже диагностика есть), т.е. в реальном мире там скорее всего будет std::string_view sv = foo(); и dangling reference никуда не денется.
В данном конкретном случае выбор между консистентностью или безопасностью :(
A a;
//...
// Direct initialization:
B b(a); // Одни правила перегрузки
// Copy initialization:
B b = a; // Другие правила перегрузки
При присваивании третьи правила.
А сколько мне головной боли из-за этого доставили библиотечные std::optional и std::tuple, из-за того что у них есть перегрузки для универсальных ссылок любого типа — U&&. Эти перегрузки настолько «жадные» что хватают практически все что не попадя, не давая никак исправить это поведение. Если в коде есть классы-врапперы которые сами могут преобразовываться к разным типам, работа с конструирование std::optional и std::tuple превращается в головную боль.
Видимо только на концепты и осталась надежда.
Хотя Линус даже _Bool до сих пор не очень жалует.
lkml.org/lkml/2013/8/31/138
yield — это доходность облигаций и введение такого ключевого слова сломает тонны финансового софта.
Такой общий вопрос к работе комитета. Недавно хотел я выяснить статус одного предложения. Я знаю номер предложения, я знаю ссылку на open-std. Но как понять, было ли оно принято или отклонено?
Судя по всему, чуть ли не единственный способ сейчас — спросить в "официальном" слаке. Ну или долго-долго листать все результаты всех встреч и искать там упоминания этого предложения, молясь, чтобы оно было там упомянуто с номером, а не просто как "Numbers TS".
Может быть, есть смысл завести хотя бы какую-нибудь табличку со статусами предложаний? Или может быть она уже есть, просто я не смог ее найти?
Историю о более старых бумагах поднять не получится, скорее всего.
Ооо, круто! Спасибо!
Вопрос по Numerics. Есть ли планы по имплементации чисел с плавающей запятой? Таким образом можно было бы double/float перевести в constexpr и consteval контексты.
Но в таком виде оно не пройдет, потому что слишком много замечаний по нему будет. Его надо сильно доделывать.
А вообще есть планы на unbounded float и разновидности decimal. Успеют ли они воплотиться в будущем Numbers TS — увидим
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
. В каком виде предлагаете делать патч?
1) Странно, вроде бы они не настолько медленные
это невероятная боль. речь идёт о форматированном вводе-выводе. исследовал как-то реализацию от msvc:
непрерывное блокирующее получение локали и использование printf убивает эффективность напроч
А так — работы обычно ведутся в этих направлениях. Если есть идеи, что да как должно выглядеть — можете написать предложение, чего именно вы хотите и отправить на рассмотрение в комитет. Рассмотрят точно и накидают комментов. Другой вопрос, что работа это очень сложная и кропотливая… :(
На мой взгляд, для большей части описанных вами вещей достаточно сделать библиотеки, и нет необходимости менять язык.
пример реально высокой производительности (желательно по критерию малой задержки) где применяется стандартный C++ на критическом пути (вектрра там, мэпы
Пожалуйста.
kdmitrii
C++ используется как нативный метод общения с ОС(для использования NUMA аллокаций например) и вставок ассемблера.
А по моему опыту, языку C++ не хватает средств для общения с ОС, посмотрите, что с сокетами, например.
И для ассемблеров C++ предназначен не очень, поскольку он сильно на кроссплатформенность ориентирован, а у платформ ассемблеры отличаются. Ассемблерные вставки в C++ вызывают разные неприятности: код достаточно сильно привязывается к комплиятору. Проще уж тогда сразу при сборке вызывать nasm, yasm, fasm (что вам нравится) и не мудрить :) Это у меня, кстати, главное разочарование, связанное с C++, после всех паскалей, где воткнуть пару MMX-инструкций в код можно хоть в делфи, хоть в FPC, даже не особо задумываясь.
Каков порядок работы с предложениями с сайта stdcpp.ru?
В частности интересует история с invoke_result_t
, о которой я писал. Из обсуждения на сайте я сделал вывод, что это никому не интересно, а теперь выясняется, что кто-то таки заинтересовался и пошёл с этим в комитет.
Баги C++20. Итоги встречи в городе Белфаст