Снова про const, не получается переползти с С на СРР Опции

[Aprox]

Искал свою проблему в форуме, но не нашел решения. Проблема в следующем. Имеется готовый проект на С для IAR-430A, кристаллы ARM ST91х. Использую структуры, состоящие из данных-констант вида:

Код

typedef struct{
  const Tsome_type  some_data1;
  const Tsome_type  some_data2;
  // ...etc
} Tsome_info;

Затем в коде на С создаю эти структуры с уже конкретными константами в полях

Код

const Tsome_info info1={,,,,,};
const Tsome_info info2={,,,,,};
const Tsome_info info3={,,,,,};
//..etc

На С все прекрасно живет, компилятор помещает мои структуры в сегмент CONST, а линкер- в ROM. Но, тот же самый код на СPP приводит к размещению структур в сегменте CSTACK вместе с другими объектами. В результате куча констант хранится в RAM, которой и так мало! Я в шоке. Можно ли как-то победить эту проблему? Или придется перелопачивать идеологию проекта?

[Oldring]

Я в шоке.

В плюсах модификатор const не гарантирует, что объект не будет изменяться во время работы программы. Для программ обычных компов это не критично. Для встроенных систем изучайте тонкости настроек компилятора, с целью заставить его поместить объект в ROM.

[dxp]

В плюсах модификатор const не гарантирует, что объект не будет изменяться во время работы программы.

Это как это? А что же тогда он гарантирует? И почему "в плюсах"? А в голом Цэ по-иному строится отношение к константным объектам?

Квалификатор const не гарантирует, что объект будет размещаться в ПЗУ (если оно вообще есть в наличие), это да. А насчет изменения очень даже гарантирует. И чтобы это обойти, придется использовать хаки (на свой страх и риск, ессно).

[Oldring]

Это как это? А что же тогда он гарантирует? И почему "в плюсах"? А в голом Цэ по-иному строится отношение к константным объектам?

В голых сях - иначе. Было у Страуструпа эссе по этому поводу.
Слово гарантирует, что программист не модифицирует объект неумышленно. Но всё равно если есть конструктор-деструктор, они будут вызваны. И иногда константные объекты мутируют. Было даже введено в язык специальное ключевое слово "mutable". Но иногда обходятся по-старинке и без него, снимая константность с указателя.

[Aprox]

А все-таки, посоветуйте новичку в "плюсах", как наиболее грамотно и экономно в смысле RAM строить объекты, которые используют предопределенные свойства в виде набора констант. Можно на хрестоматийном примере компонента ComboBox. Там используется куча свойств-констант. Отсюда вопрос- как в Embedded С++ сделать так, чтобы свойства-константы оказались в ROM, а конструктор TComboBox выглядел бы прилично?

[AHTOXA]

как в Embedded С++ сделать так, чтобы свойства-константы оказались в ROM, а конструктор TComboBox выглядел бы прилично?

Ну вы всё правильно делаете - константные структуры, и указатель на них в качестве параметра конструктора.

Если объектов немного, то можно шаблонами. Типа

Код

struct ComboProps1
{
    enum { width = 200 };
    enum { height = 500 };
    enum { some_bool_prop1 = false };
    ...
};

struct ComboProps2
{
    enum { width = 300 };
    enum { height = 200 };
    enum { some_bool_prop1 = true };
    ...
};

template<typename Props> class TComboBox
{
    enum { width = Props::width };
...
}

TComboBox<ComboProps1> Combo1;
TComboBox<ComboProps2> Combo2;

[Aprox]

Ну вы всё правильно делаете - константные структуры, и указатель на них в качестве параметра конструктора.

Ваш вариант задания констант-описаний выглядит читабельно и красиво. Однако, если в структуре-описания много разных типов, например, строки, указатели на места памяти, float и пр., то ваш вариант приводит к излишней писанине в момент декларации самих констант. Мне кажется, следующий вариант экономней в смысле писанины

Код

typedef struct{
   int i;
   float f;
   char* s;
} Tprops;

//----здесь декларации свойств с экономией писанины
static const Tprops prop1 ={13, 3.14, "Name1"}; // это точно попадает в ROM
static const Tprops prop2 ={16, 2.73, "Name2"}; // это точно попадает в ROM

class Tobj {//-------------
  const Tprops* p;
public:
  Tobj(){}
  Tobj(const Tprops* prop) {p=prop;}
  
// здесь можно пользоваться элементами описания *p.f или p->i
};

Tobj example1=&prop1;
Tobj example2=&prop2;

...

[AHTOXA]

Мне кажется, следующий вариант экономней в смысле писанины

Дык, моя фраза

константные структуры, и указатель на них в качестве параметра конструктора.

была как раз про этот вариант А с шаблонами - это альтернативный.

[Aprox]

А с шаблонами - это альтернативный.

Я про шаблоны и говорю, что писанины больше при инициализации полей структуры-описания. В каждом конкретном определении структуры свойств придется набирать имена полей и все сопутствующее. Кроме того, шаблоны не поддерживает Embedded C++, а переходить на Extended C++ сразу утяжеляет проект ненужными фичами.

Я тут подумал, можно несколько повысить быстродействие, если передавать конструктору класса не указатель на структуру-описание, а ссылку на эту структуру. Заодно и в методах классах обращение к описаниям будет выглядеть приятнее.

[AHTOXA]

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

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

Код

    if (some_bool_prop1)
        func1();
    else
        func2();

при some_bool_prop1 == true будет скомпилирован в

Код

    func1();

За счет чего будет подъем быстродействия? Как вы представляете внутренюю реализацию ссылки кроме как через указатель?

Может, для ссылки на константу есть надежда, что компилятор подставит константу прямо в код?

[Aprox]

Может, для ссылки на константу есть надежда, что компилятор подставит константу прямо в код?

Подскажите, какие существуют методы для проверки подобных гипотез? Дисассемблер?

[AHTOXA]

А как иначе?
Ну или можно скомпилировать оба варианта и сравнить размеры получившихся программ.

[Aprox]

А как иначе?
Ну или можно скомпилировать оба варианта и сравнить размеры получившихся программ.

Попробовал. Дисассемблером не лазил, а размеры программ сравнил. Практически неотличимо.

Как передавать создаваемому объекту структуру из констант разобрался. Прошу дальнейшей помощи идейного плана. Сейчас уперся в другое. Задача стоит прорисовывать в окне разнородные объекты, например. TComboBox, TCheckBox. TRadioButton..etc., каждый имеет свое описание в виде структур констант, тоже разнотипных. Я думал создать базовый класс TObj с виртуальной функцией прорисовки и от него уже наследовать разнотипные классы, каждый со своей конкретной прорисовкой. Далее думал создать массив указателей на базовые объекты прорисовки и в цикле, по очереди вызывать функцию прорисовки базового объекта.
Тупик наступил на этапе- где должен размещаться указатель на структуру описание, в базовом, или наследуемом классе? По идее в наследуемом. Но тогда до нее не доберешься из базового класса, а ведь цикл прорисовки идет именно по списку из указателей на базовые. Если структуру-констант разместить в базовом классе, то теряется вся идея, поскольку структуры все разного типа и указать конкретно один тип, базовый, не представляется возможным. Прошу совета у гуру С++ - как быть? Также прошу иметь в виду, что речь идет об ARM кристаллах, в которых RAM - маловато, а ROM- много больше. Т.е. по-прежнему загвоздка с директивой const.

[AHTOXA]

По идее в наследуемом. Но тогда до нее не доберешься из базового класса, а ведь цикл прорисовки идет именно по списку из указателей на базовые.

До неё и не надо добираться. Доступ к ней будет из функции Draw() наследуемого класса. А к функции Draw() доступ по указателю на базовый класс есть, так что всё в порядке.

[Aprox]

До неё и не надо добираться. Доступ к ней будет из функции Draw() наследуемого класса. А к функции Draw() доступ по указателю на базовый класс есть, так что всё в порядке.

Спасибо, все получилось.