История изменений

Тут, кстати, отдельный и открытый вопрос о том, сколько усилий нужно приложить, чтобы написать корректный код, который бы правильно удалял старый экземпляр и создавал бы новый экземпляр в области памяти старого. Особенно с учетом обеспечения exception safety.

Я считаю - без внешней индикации «объект существует» (std::optional в случае отдельных объектов, size vs capacity в vector’е etc) это тупо невозможно.

Так что это, скорее, антипаттерн, который должен применяться в исключительных случаях. В частности, в ситуациях, когда demo – это trivially destructible. В этом случае разницей между количеством конструкторов и деструкторов можно пренебречь.

Согласен по всем пунктам. Более того - знаю места в нашем prod коде где это встречается. Решили не тратить на это время (хотя поправить было несложно) именно по причине «не выстрелит» - всегда имеются гораздо более приоритетные задачи где выхлоп будет реально ощутим (я думаю - у остальных примерно то же самое, в конве choose your fight wisely).

Тут, кстати, отдельный и открытый вопрос о том, сколько усилий нужно приложить, чтобы написать корректный код, который бы правильно удалял старый экземпляр и создавал бы новый экземпляр в области памяти старого. Особенно с учетом обеспечения exception safety.

Я считаю - без внешней индикации «объект существует» (std::optional в случае отдельных объектов, size vs capacity в vector’е etc) это тупо невозможно.

Так что это, скорее, антипаттерн, который должен применяться в исключительных случаях. В частности, в ситуациях, когда demo – это trivially destructible. В этом случае разницей между количеством конструкторов и деструкторов можно пренебречь.

Согласен по всем пунктам. Более того - знаю места в нашем prod коде где это встречается. Решили не тратить на это время (хотя поправить было несложно) именно по причине «не выстрелит» - всегда имеются гораздо более приоритетные задачи где выхлоп будет реально ощутим (я думаю - у остальных примерно тоже самое, в конве choose your fight wisely).

Тут, кстати, отдельный и открытый вопрос о том, сколько усилий нужно приложить, чтобы написать корректный код, который бы правильно удалял старый экземпляр и создавал бы новый экземпляр в области памяти старого. Особенно с учетом обеспечения exception safety.

Я считаю - без внешней индикации «объект существует» (std::optional в случае отдельных объектов, size vs capacity в vector’е etc) это тупо невозможно.

Так что это, скорее, антипаттерн, который должен применяться в исключительных случаях. В частности, в ситуациях, когда demo – это trivially destructible. В этом случае разницей между количеством конструкторов и деструкторов можно пренебречь.

Согласен по всем пунктам. Более того - знаю места в нашем prod коде где это встречается. Решили не тратить на это время (хотя поправить было несложно) именно по причине «не выстрелит» - всегда имеются гораздо более приоритетные задачи где выхлоп будет реально ощутим (я думаю - у остальных примерно тоже самое, в конве chose your fight wisely).