Если new будет использоваться только как замена глобальным объектам, то фрагментация ему не грозит, ибо будет только new, без delete. Но если

, то я только за
ЗЫ. Пока прикрутил bget, вроде работает.

А тогда смысла нет в динамическом управлении памятью. Смысл ведь в том, чтобы юзать одну и ту же память под разные цели в разные моменты времени. Как стек, только со временем жизни объектов, определяемым пользователем. А если без delete, то тот вариант во статиками внутри получается функционально почти такой же, а по накладным лучше.

Смысл в том, что объекты создаются в нужном мне порядке, я управляю этим.
Насчёт увеличения накладных - это вряд ли. ну разве что при создании объекта. При работе - простейшая проверка на null и возврат.
Естественно, если будут нормальные new/delete, то лучше использовать их.

От неопределенности порядка вызовов конструкторов глобальных объектов ты не избавишься, размещая объект в свободной памяти вместо того, чтобы завести его статиком внутри функции. Это имелось в виду.

А, это конечно. Просто наличие new позволяет даже без всяких синглетонов делать

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

Да, это удобная штука (а местами незаменимая - сейчас приходится с GUI колупаться, очень не хватает простого, легкого и безопасного менеджера памяти. И для STL'ных вещей оно тоже очень нужно, там, правда, придется аллокаторы переписать). Надо будет поставить приоритетной в очередь факультативных задач.


Адназначна.