указатель, а затем объект после нового оператора в C ++ [duplicate]

Полезно, если вы создаете ядро ​​- где вы помещаете код ядра, который вы читаете с диска или в pagetable? Вы должны знать, куда прыгать.

Или в других, очень редких случаях, например, когда у вас много загруженной комнаты и вы хотите разместить несколько структур друг за другом. Они могут быть упакованы таким образом без использования оператора offsetof (). Однако есть и другие трюки.

Я также считаю, что в некоторых реализациях STL используется новое размещение, например std :: vector. Таким образом, они выделяют место для 2 ^ n элементов и не нуждаются всегда в realloc.

Одно место, через которое я столкнулся, находится в контейнерах, которые выделяют смежный буфер, а затем заполняют его объектами по мере необходимости. Как уже упоминалось, std :: vector может это сделать, и я знаю, что некоторые версии MFC CArray и / или CList сделали это (потому что именно там я впервые столкнулся с ним). Метод перераспределения буфера - очень полезная оптимизация, а размещение нового - это почти единственный способ построить объекты в этом сценарии. Он также иногда используется для создания объектов в блоках памяти, выделенных вне вашего прямого кода.

Я использовал его в аналогичной емкости, хотя он часто не возникает. Это полезный инструмент для инструментария C ++.

Это также полезно, если вы хотите повторно инициализировать глобальные или статически распределенные структуры.

Старый способ C использовал memset() для установки всех элементов на 0. Вы не можете сделать это на C ++ из-за vtables и конструкторов пользовательских объектов.

Поэтому я иногда использую следующие

 static Mystruct m;

 for(...)  {
     // re-initialize the structure. Note the use of placement new
     // and the extra parenthesis after Mystruct to force initialization.
     new (&m) Mystruct();

     // do-some work that modifies m's content.
 }

Механизмы сценариев могут использовать его в собственном интерфейсе для выделения собственных объектов из скриптов. Для примера см. Angelscript (www.angelcode.com/angelscript).

Размещение new также очень полезно при сериализации (скажем, с boost :: serialization). В 10 лет c ++ это только второй случай, когда мне нужно новое место для размещения (третий, если вы включаете интервью :)).

Я думаю, что это не было подчеркнуто каким-либо ответом, но еще один хороший пример и использование для нового места размещения - это сокращение фрагментации памяти (с помощью пулов памяти). Это особенно полезно для встроенных и высокодоступных систем. В этом последнем случае это особенно важно, потому что для системы, которая должна работать 24/365 дней, очень важно не иметь фрагментации. Эта проблема не имеет ничего общего с утечкой памяти.

Даже когда используется очень хорошая реализация malloc (или аналогичная функция управления памятью), очень долго приходится разбираться с фрагментацией. В какой-то момент, если вы не умеете рационально использовать вызовы резервирования / выпуска памяти, вы можете получить множество небольших пробелов, которые трудно повторно использовать (назначить новые оговорки). Таким образом, одним из решений, которые используются в этом случае, является использование пула памяти для распределения перед собой памяти для объектов приложения. После каждого раза, когда вам нужна память для какого-либо объекта, вы просто используете новое место размещения для создания нового объекта в уже зарезервированной памяти.

Таким образом, после запуска вашего приложения у вас уже есть вся необходимая память. Все новые резервирования / освобождения памяти относятся к выделенным пулам (у вас может быть несколько пулов, по одному для каждого класса объектов). В этом случае не происходит фрагментации памяти, так как не будет пробелов, и ваша система может работать в течение очень длительных периодов (лет) без фрагментации.

Я видел это на практике специально для VoxWorks RTOS, поскольку его система распределения памяти по умолчанию сильно страдает от фрагментации. Поэтому выделение памяти с помощью стандартного метода new / malloc было в основном запрещено в проекте. Все резервирования памяти должны поступать в выделенный пул памяти.

Я использовал его для создания объектов на основе памяти, содержащей сообщения, полученные из сети.

Я использовал его в режиме реального времени. Обычно мы не хотим выполнять любое динамическое распределение (или освобождение) после запуска системы, потому что нет никакой гарантии, сколько времени это займет.

То, что я могу сделать, это предустановить большой кусок памяти (достаточно большой, чтобы удержать любое количество того, что может потребоваться классу). Затем, когда я выясню во время выполнения, как построить вещи, размещение new можно использовать для построения объектов прямо там, где я их хочу. Одна из ситуаций, которые я знаю, я использовал, чтобы помочь создать гетерогенный круговой буфер .

Это, конечно, не для слабонервных, но именно поэтому они делают для него синтаксис угловатый.

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

Возьмите контейнеры наподобие unordered_map, vector или deque. Все они выделяют больше памяти, чем минимально требуется для вставленных вами элементов, чтобы избежать необходимости распределения кучи для каждой отдельной вставки. Давайте используем vector в качестве простейшего примера.

Когда вы это делаете:

vector<Foo> vec;

// Allocate memory for a thousand Foos:
vec.reserve(1000);

... который фактически не создает тысячу Foos. Он просто выделяет / резервирует память для них. Если vector не использовал здесь место размещения, это было бы построение по умолчанию Foos по всему месту, а также необходимость вызывать их деструкторы даже для элементов, которые вы никогда не вставили в первую очередь.

Allocation! = Construction, Freeing! = Destruction

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

Должно быть разделение между этими идеями, чтобы избежать излишнего вызова конструкторов и деструкторов излишне левым и правым, и поэтому стандартная библиотека разделяет идею std::allocator (которая не создает или не уничтожает элементы, когда он выделяет / освобождает память *) вдали от используемых им контейнеров, которые вручную создают элементы, используя размещение новых и вручную уничтожая элементы, используя явные вызовы деструкторов.

Foo* foo = new(free_list.allocate()) Foo(...);
...
foo->~Foo();
free_list.free(foo);

Это полезно, если вы хотите отделить выделение от инициализации. STL использует новое размещение для создания элементов контейнера.

Как правило, размещение нового используется, чтобы избавиться от стоимости распределения «нормального нового».

Другой сценарий, в котором я использовал его, - это место, где я хотел иметь доступ к указателю к объекту, который еще должен был быть сконструирован, для реализации одноэлементного документа.