[brag 0]

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

 

[Axel 1]

Поэтому в типичном эмбеддед-приложении...

Поймите-же эту простую мысль, кучефилы, и творения ваши станут чуть менее глючными!!! :)

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

[brag 0]

несколькими альтернативными режимами

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

[Axel 1]

...и placement new.

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

[brag 0]

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

И ни одно слово не простаивает. В случаи с кучей надо иметь запас

[Axel 1]

...размер пула определяется на этапе компиляции...

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

[ReAl 0]

А как Вы это делаете?

Ну выше ж написано - pool[ MAX( ) ]

Т.е. цепочака макросов MAX с sizeof() классов, на этом форуме вроде уже не раз placement new обсуждался..

Можно и как-то так, чтобы длинные MAX не писать и условной компиляцией включать/выключать применение (не помню, писал ли раньше):

#define SIZE_IN(class, type)  ((sizeof(class)+sizeof(type)-1)/sizeof(type))

#define POOL_PLACE(class) uint8_t place_for_##class [ sizeof(class) ]

#include "A.h"

#ifdef MODE_B_USED
#   include "B.h"
#endif

#include "C.h"

union pool1_member_sizes
{
    POOL_PLACE(A);
#ifdef MODE_B_USED
    POOL_PLACE(B);
#endif
    POOL_PLACE(C);
};

// автоматически получаем MAX всех размеров
uint32_t pool1[ SIZE_IN(pool1_member_sizes,uint32_t) ];

[Axel 1]

Можно и как-то так...

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

[brag 0]

Тогда уж красивее так вроде, зачем лишний макро?

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

#define SIZE_IN(class, type)  (sizeof(class)/sizeof(type))

#include "A.h"

#ifdef MODE_B_USED
#   include "B.h"
#endif

#include "C.h"

union pool1_member_sizes{
    А а;
#ifdef MODE_B_USED
    B b;
#endif
    C c;
};

// автоматически получаем MAX всех размеров
uint32_t pool1[ SIZE_IN(pool1_member_sizes,uint32_t) ];

[ReAl 0]

Ага, щас.

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

#define POOL_PLACE(class) class a_##class

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

pn.cpp:31: error: member ‘A pool1_member_sizes::a_A’ with constructor not allowed in union

И ручное выравнивание можно убрать и на 8-/16битных юзать вместо uint32_t соответствующій тип.

Да кто его знает...

Вот вдруг «захочется» на CM3 ровнять такие пулы на двойное слово, uint64_t.

А sizeof даст в байтах округлённое вверх до uint32_t.

И у какого-то класса будет их (uint32_t) нечётное количество.

И даст sizeof(отой_union)/sizeof(uint64_t) отбрасывание «лишнего» uint32_t и нехватку места в буфере.

Мне проще каждый раз вместо A/B написать (A+B-1)/B чем думать, где отсутствие округления вверх может вілезти боком.

Лишней памяти такая запись точно никогда не запросит, нехватки тоже гарантированно не будет, в отличие от A/B.