std :: allocator construct/destroy vs. placement new/p-> ~ T()

Question

Для моего проекта я пишу некоторые контейнеры STL с нуля (у меня есть причины). Поскольку я имитирую функциональность и интерфейсы STL так близко, я прилагаю все усилия, чтобы придерживаться политики «если она имеет то же имя, что и стандартная конструкция, она будет соответствовать стандарту как можно больше».

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

Интерфейс std::allocator отделяет выделение памяти от конструкции объекта. Также он отделяет освобождение от разрушения. Это имеет смысл с тех пор, как вы получаете память из более или менее неуместного для правильного построения объекта в C++.

Таким образом, есть две строительные/отмена функции, которые выглядят, как это для реализации по умолчанию (поднятой прямо из книги):

void construct(pointer p, const T& val) { new(p) T(val); } 
void destroy(pointer p)     { p->~T(); } 

, как вы можете видеть, построить просто вызывает размещение нового и уничтожить просто вызывает деструктор ,

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

Более конкретно, можно ли сказать, что я всегда могу использовать std::uninitialized_copy и std::uninitialized_fill для конструирования элементов моих контейнеров?

Спасибо.

Answer 1

Распределитель может добавлять отчеты о регистрации до и после строительства/уничтожения или любые другие побочные эффекты, о которых он мог бы подумать.

Конечно фактическое строительство должно происходить путем вызова размещения новых и деструктор, но в своде правил он не говорит, что ничего другого не должно произойти в конструкции/уничтожить ФУНКЦИИ

Answer 2

Это просто, чтобы скрыть детали распределения в методе. то есть мы предоставляем API для строительства и разрушения, в будущем мы сможем изменить реализацию. Теперь мы используем новое размещение для выделения памяти, в будущем, если мы хотим изменить распределение, нам просто нужно изменить эти два метода.