Планируется ли пересмотр интерфейса std::allocator для будущих версий C++?

Question

В своем выступлении в 2015 году Андрей Александреску описывает некоторые зверства интерфейса std::allocator, вкратце подчеркивая, что на самом деле речь идет не о распределении, и предлагает другой способ мышления об этих распределителях, который сделает их более удобными и модульными. Или, если процитировать описание:

У std::allocator бесславное прошлое, мрачное настоящее и безрадостное будущее. STL представил распределители памяти как временный барьер для устаревших моделей сегментированной памяти 1990-х годов. Их дизайн был ограничен и во многих отношениях даже не был нацелен на то, чтобы так сильно помочь распределению. Поскольку там были распределители, они просто продолжали оставаться там до тех пор, пока их не стало невозможно ни искоренить, ни заставить работать, несмотря на отважные усилия, приложенные сообществом.

В этом докладе обсуждается полная конструкция распределителя памяти, созданная из первых принципов. Он является универсальным, разбит на компоненты и может быть составлен для поддержки шаблонов распределения для конкретных приложений.

Его основные аргументы против текущего std::allocator содержатся в этом разделе видео, но вкратце:

1. Распределители не должны заботиться о выделяемом типе, а только о размере и выравнивании.
2. Распределители не должны нести ответственность за хранение информации о размере выделения, выделения и освобождения должны симметрично (соответственно) возвращать и получать Blk (птр, размер).
3. Rebind<U>::other ужасно (он не вдавался в подробности)
4. Распределители не должны иметь состояния (поскольку они буквально дают вам части памяти, как они могут быть без состояния?)
5. Распределители следует определять вокруг концепции композиции; Если вы посмотрите на распределители в реальном мире, все они состоят из небольших распределителей, которые выполняются условно.

С тех пор, как я посмотрел это выступление, я ожидал, что из него последует какое-то предложение, поскольку идея казалась такой здравой и полезной. В прошлом мне приходилось работать с std::allocator, и это заставило меня впервые понять необходимость концепций C++ 20, когда мой экран кричал на меня, когда функция кандидата нежизнеспособна.

Но вроде ничего из этого не вышло? В то время меня не было, но похоже, что STL2 был в разработке, но с тех пор он был прекращен. Было ли где-то решено, что концепций будет достаточно, чтобы хотя бы устранить симптомы std::allocator (если да, то где / когда?), Или это проблема обратной совместимости? Есть ли что-то связанное с этим в планах будущей версии C++?

Answer 1

Нет никаких предложений по радикальному изменению модели распределителя. Это в основном по двум причинам.

Библиотека контейнеров C++ полагается на распределители, работающие определенным образом, и было бы крайне сложно создать контейнеры, которые работали бы с обоими типами распределителей. Итак, если вам нужна новая модель распределителя, вы также говорите о новом наборе контейнеров, который представляет собой огромную банку червей, которую комитет не хотел открывать.

В наши дни большинство недостатков в создании и использовании распределителя можно избежать. Написать распределитель даже на C++ 17 не так уж сложно. Вам не нужно разбираться в кровавых подробностях дела; вам просто нужно реализовать пару функций и несколько псевдонимов членов. std::allocator_traits заполняет за вас большую часть пропусков.

В конце концов, в языке и библиотеке C++ есть существенные недостатки, которые более важны, чем модель распределителя, которую труднее использовать, чем это строго необходимо.

Answer 2

Мы уже имеем std::pmrпостроенный на основе распределителей, который решает все перечисленные проблемы.