Убедить международный комитет не дублировать все контейнеры стандартной библиотеки

yndx-antoshkka
yndx-antoshkka

В std::constexpr_vector<T> предлагается сделать специальный контейнер, который сможет аллоцировать память в константных выражениях и который можно будет использовать только в constexpr функциях только если они в constexpr контексте.

Идея отличная, но потенциально выльется в дублирование всех контейнеров стандартной библиотеки с припиской constexpr_.

Необходимо убедить международный комитет в том, что возможно модифицировать уже имеющиеся контейнеры так, что их можно будет использовать в constexpr.

Предложение: Changing attack vector of the constexpr_vector

13
рейтинг
сделано в РГ21
9 комментариев
zamazan4ik@tut.by

А разве ещё не убедили избежать дублирования?

zamazan4ik@tut.by
yndx-antoshkka

Убедили. Поэтому у задачи тег "сделано в РГ21"

yndx-antoshkka
edc0a91c24342ae88891

yndx-antoshkka, а есть какие-то подвижки в сторону "снятия константности" с constexpr?

edc0a91c24342ae88891
yndx-antoshkka

Надо писать бумагу с подробностями. Опишите где это мешает, что хочется починить. Пока кажется что комитет идею отбросит, как ломающую обратную совместимость

yndx-antoshkka
edc0a91c24342ae88891

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 выше.

edc0a91c24342ae88891
languagelawyer

> Убедили. Поэтому у задачи тег "сделано в РГ21"

А когда убедили? Идеи разрешить new в константных выражениях (что позволит сделать constexpr аллокаторы и следовательно constexpr контейнеры) гуляют года с 13-го.

languagelawyer
yndx-antoshkka

languagelawyer, идея гуляла. Один из разработчиков компиляторов в течение 2х лет пытался реализовать эту идею и хороший результат не получил. После чего решил сосредоточиться на создании специального constexpr_ контейнера. Данный путь в дальнейшем вёл к дублированию всех контейнеров и классов с приставкой constexpr_.

В итоге в бумаге мы показали, что можно обойтись только constexpr аллокатором и добавлением constexpr к имеющимся контейнерам. Посмотрев на код аллокатора, разработчик нашёл для себя фишку: можно заставить аллокатор сразу конструировать нужный тип данных при аллокации. Это избавляет от основной проблемы - слежением в constexpr контексте за типом (который erased при возвращении алокатором void*/char*) и временем жизни type erased объекта.

Дальнейшие изыскания позволили разработчику пойти дальше и сделать constexpr new вместо constexpr_allocator. Такой new просто оставляет за бортом все type erased случаи и не считает их constexpr (этого достаточно для создания constexpr контейнеров, как было показано в бумаге от РГ21).

yndx-antoshkka
languagelawyer

> можно заставить аллокатор сразу конструировать нужный тип данных при аллокации

И насколько это совместимо с требованиями к аллокаторам?

languagelawyer
yndx-antoshkka

languagelawyer, это ещё предстоит обсудить. Возможно, что вместо использования std::allocator контейнеры будут допатчены std::is_constexpr_evaluated(). Это уберёт зависимость на std::allocator (что обрадует embedded разработчиков) но добавит немного кода в стандартные контейнеры

yndx-antoshkka
Другие идеи
Группа создана, чтобы собирать предложения к стандарту C++, организовывать их внутренние обсуждения, помогать готовить их для отправки в комитет и защищать на общих собраниях в рабочей группе по С++ Международной организации по стандартизации (ISO).
Все предложения