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

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

в моей практике тоже такое часто, обычно весь рижим в итоге упакован в 1 класс(а внутри уже может быть куча обьектов, втч классов общих для разных режимов) и placement new.

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

практически да. только в моем случаи размер пула определяется на этапе компиляции U32 pool[MAX(sizeof(class1),sizeof(class2),...)/4];
И ни одно слово не простаивает. В случаи с кучей надо иметь запас

А как Вы это делаете? Я, поскольку так не умею, делаю это как часть инициализации: определяю макс. размер класса, выделяю пул из кучи, и уже его потом использую для placement new... Кривовато выглядит

Ну выше ж написано - pool[ MAX( ) ]
Т.е. цепочака макросов MAX с sizeof() классов, на этом форуме вроде уже не раз placement new обсуждался..
Можно и как-то так, чтобы длинные MAX не писать и условной компиляцией включать/выключать применение (не помню, писал ли раньше):

Спасибо, технично, уже включил в код.

Тогда уж красивее так вроде, зачем лишний макро?
И ручное выравнивание можно убрать и на 8-/16битных юзать вместо uint32_t соответствующій тип. Хотя, без разницы

Ага, щас.
Заменяем (так быстрее, чем union редактировать):

Получаем кучу в духе:

Да кто его знает...
Вот вдруг «захочется» на CM3 ровнять такие пулы на двойное слово, uint64_t.
А sizeof даст в байтах округлённое вверх до uint32_t.
И у какого-то класса будет их (uint32_t) нечётное количество.
И даст sizeof(отой_union)/sizeof(uint64_t) отбрасывание «лишнего» uint32_t и нехватку места в буфере.
Мне проще каждый раз вместо A/B написать (A+B-1)/B чем думать, где отсутствие округления вверх может вілезти боком.
Лишней памяти такая запись точно никогда не запросит, нехватки тоже гарантированно не будет, в отличие от A/B.