C++ в микроконтроллерах, посветите безграмотного. Опции

[-=Sergei=-]

Имеем ARM Cortex-M3.

Ядро за командами лазит в флеш через шину Icode, за данными через system в ОЗУ. Конфликтов нет, работаем быстро.

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

[IgorKossak]

С объектами производных классов тоже не просто.
Даже если нет private членов как проинициализировать следующий объект?

Код

class cls
{
    public:
        virtual int foo(void) const = 0;
};

class boo : public cls
{
    public:
        int a;
        int b;
        int foo(void) const;
};

extern const boo b;

const boo b =????;

[dxp]

С объектами производных классов тоже не просто.

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

Так я и написал что реально просто структура с методами. Но я предпочитаю писать как class что бы отличать от просто структур, которые не имеют методов. К тому же это не совсем POD - потому что метод foo там есть и совместимости с С уже нет.

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