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

[-=Sergei=-]

Имеем ARM Cortex-M3.

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

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

[KRS]

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

объект создается не в ОЗУ, а в определенном сегменте/секции. Причем там располагаются исключительно данные и указатель на VMT, а все функции (они в одном экземпляре для каждого класса) остаются в сегменте/секции кода.

[IgorKossak]

объект создается не в ОЗУ, а в определенном сегменте/секции

, который/которая должны находиться таки в ОЗУ, т. к. в read-only памяти объект не может быть сконструирован

[KRS]

, который/которая должны находиться таки в ОЗУ, т. к. в read-only памяти объект не может быть сконструирован

который объявлен глобально и как const может.

[IgorKossak]

который объявлен глобально и как const может.

Именно так и объявленный объект создаётся In section .bss, а также создаются конструкторы, пишущие в эту область памяти.

[KRS]

Именно так и объявленный объект создаётся In section .bss, а также создаются конструкторы, пишущие в эту область памяти.

Объект может не иметь конструктора. и все методы могут быть конст. Вот пример который кидает данные в скецию .rodata
Это конечно простой объект без VMT - реально просто структура с методами. Но такой подход может быть полезен никакого оверхида

Код

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

extern const cls a;
extern const cls b;

const cls a = {4,5};
const cls b = {6,7};

int cls::foo(void) const
{
    return a + b;
}

а вот листинг

Код

   \                                 In section .rodata, align 4
     11          const cls a = {4,5};
   \                     a:
   \   00000000   040000000500       DC32 4, 5
   \              0000        

   \                                 In section .rodata, align 4
     12          const cls b = {6,7};
   \                     `b`:
   \   00000000   060000000700       DC32 6, 7
   \              0000        
     13          

   \                                 In section .text, align 4, keep-with-next
     14          int cls::foo(void) const
     15          {
     16              return a + b;
   \                     _ZNK3cls3fooEv:
   \   00000000   0168               LDR      R1,[R0, #+0]
   \   00000002   4068               LDR      R0,[R0, #+4]
   \   00000004   0818               ADDS     R0,R1,R0
   \   00000006   7047               BX       LR              ;; return
     17          }
     18

[dxp]

Объект может не иметь конструктора. и все методы могут быть конст. Вот пример который кидает данные в скецию .rodata
Это конечно простой объект без VMT - реально просто структура с методами. Но такой подход может быть полезен никакого оверхида

Код

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

Тут у вас объявлен POD тип. На самом деле это просто обычная С-структура. POD типы могут лежать в RO памяти без проблем, как и подобает обычным С-типам. Правильнее было бы просто написать:

struct cls { ... };

Заведите хотя бы одно не public поле, все станет не так шоколадно.