apolukhin
commented
3 years ago zamazan4ik@tut.by, 3 мая 2018, 16:55 А разве ещё не убедили избежать дублирования?
yndx-antoshkka, 3 мая 2018, 17:14 Убедили. Поэтому у задачи тег "сделано в РГ21"
edc0a91c24342ae88891, 18 мая 2018, 5:34 yndx-antoshkka, а есть какие-то подвижки в сторону "снятия константности" с constexpr?
yndx-antoshkka, 18 мая 2018, 12:46 Надо писать бумагу с подробностями. Опишите где это мешает, что хочется починить. Пока кажется что комитет идею отбросит, как ломающую обратную совместимость
edc0a91c24342ae88891, 28 мая 2018, 14:22 yndx-antoshkka, Я уже описал основные моменты в предложении, да и тут множество костылей на эту тему существует: https://stdcpp.ru/proposals/f0075759-68a5-47e4-b39b-8cfc76c33448 , if constexpr, https://stdcpp.ru/proposals/3bf4d05f-e934-4e0e-a1f9-c46b44341980 - моё предложение.
Хорошо, я накидаю примеров. Их миллионы и они очевидны - тот же constexpr счётчик. Нужность его сложно переоценить. Тот же constexpr for выше.
languagelawyer, 1 июня 2018, 13:28
Убедили. Поэтому у задачи тег "сделано в РГ21"
А когда убедили? Идеи разрешить new в константных выражениях (что позволит сделать constexpr аллокаторы и следовательно constexpr контейнеры) гуляют года с 13-го.
yndx-antoshkka, 1 июня 2018, 20:30 languagelawyer, идея гуляла. Один из разработчиков компиляторов в течение 2х лет пытался реализовать эту идею и хороший результат не получил. После чего решил сосредоточиться на создании специального constexpr контейнера. Данный путь в дальнейшем вёл к дублированию всех контейнеров и классов с приставкой constexpr.
В итоге в бумаге мы показали, что можно обойтись только constexpr аллокатором и добавлением constexpr к имеющимся контейнерам. Посмотрев на код аллокатора, разработчик нашёл для себя фишку: можно заставить аллокатор сразу конструировать нужный тип данных при аллокации. Это избавляет от основной проблемы - слежением в constexpr контексте за типом (который erased при возвращении алокатором void/char) и временем жизни type erased объекта.
Дальнейшие изыскания позволили разработчику пойти дальше и сделать constexpr new вместо constexpr_allocator. Такой new просто оставляет за бортом все type erased случаи и не считает их constexpr (этого достаточно для создания constexpr контейнеров, как было показано в бумаге от РГ21).
languagelawyer, 2 июня 2018, 10:44
можно заставить аллокатор сразу конструировать нужный тип данных при аллокации
И насколько это совместимо с требованиями к аллокаторам?
yndx-antoshkka, 13 июня 2018, 12:12 languagelawyer, это ещё предстоит обсудить. Возможно, что вместо использования std::allocator контейнеры будут допатчены std::is_constexpr_evaluated(). Это уберёт зависимость на std::allocator (что обрадует embedded разработчиков) но добавит немного кода в стандартные контейнеры
Перенос предложения: голоса +16, -0 Автор идеи: yndx-antoshkka
Есть предложение по созданию constexprvector. Идея хорошая, но потенциально выльется в дублирование всех контейнеров стандартной библиотеки с припиской constexpr.
Стоит показать альтернативы такому подходу.
В std::constexpr_vector
Идея отличная, но потенциально выльется в дублирование всех контейнеров стандартной библиотеки с припиской constexpr_.
Необходимо убедить международный комитет в том, что возможно модифицировать уже имеющиеся контейнеры так, что их можно будет использовать в constexpr.
Предложение: "Changing attack vector of the constexpr_vector" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0639r0.html