Снова про 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". Но иногда обходятся по-старинке и без него, снимая константность с указателя.

[dxp]

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

Ни конструктор, ни деструктор не изменяют константных членов-данных. Только создают или удаляют. То, что это не очень вяжется с концепциями реализации ПЗУ - так ПЗУ и константы - это разные вещи. В конструкторе допускается инициализация константных полей, но только в списке инициализации, в теле конструктора уже нет. И работает это только для целых (почему такое ограничение, не знаю). Т.ч. ничего там не меняется.

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

mutable - это из другой песни. Это нужно, чтобы можно было отдельные поля модифицировать в фукнциях-членах, объявленных как const. Заметьте, что речь идет не о константных членах-данных. Такие данные изменить не получится в любом случае.

[jorikdima]

Такие данные изменить не получится в любом случае.

const_cast<>() ?

[dxp]

const_cast<>() ?

После const_cast<> компилятор "умывает руки" и никакой защиты и проверок со его стороны стороны нет. Речь шла о безопасных преобразованиях (для чего умышленно вводят const в объявления) по правилам языка - так вот они не допускают модификации константных объектов.

После явного снятия константности - легко.

Ага. А еще метод:

const int a = 10;

int addr = (int)&a;

int *p = (int*)addr;

(*p)++;

И еще много таких финтов можно придумать. Только речь о конструкциях языка, а не о хаках