C++ в IAR, проблемы с оператором new Опции

[A_Sherbakov]

Здравствуйте, у меня возникла проблема. Хочу при разработке использовать все прелести С++, но при первом же динамическом создании объекта натолкнулся на проблему.

Код

class eArp:eMac{
public:
    struct t_ARPlayer{
        u16 Hard;
        u16 Prot;
        u8 HA_Len;
        u8 PA_Len;
        u16 Code;
        u8 MACSrc[6];
        u8 IPSrc[4];
        u8 MACDest[6];
        u8 IPDest[4];
    };t_ARPlayer * ArpLayer;
    u16 fg;
    eArp(u8 * data):eMac(data){
        this->ArpLayer = (t_ARPlayer*)data+14;
        this->fg = 16;
    }
};

вот так все хорошо:

Код

eArp arp2((u8 *)EnetDmaRx[Index].pBuffer);

а вот так все плохо:

Код

eArp * arp1 = new eArp((u8 *)EnetDmaRx[Index].pBuffer);

когда программа доходит до конструктора в data адрес нормальный, и после прохождения строчки
this->ArpLayer = (t_ARPlayer*)data+14;
адрес this->ArpLayer равен 0

аналогично с полем fg, должно становиться 16. а равно нулю.

[WitFed]

Может там в настройках ИАР есть переключатели типа "Жутко стандартный ++"/"Для нормальных пацанов" ?
А память хоть в new выделилась, this не нулевой ?
Можно в отладчике походить, все тонкости исследовать, где чего по ASM-у не хватает, да накатать жалобу производителям ?
Для меня лично во втором случае никаких проблем -- на текущем уровне нужно получить результат new и передать его в конструктор, а в первом -- сразу адрес переменной в стеке. Вроде как проблема будет, если куча вообще не включена.

[A_Sherbakov]

Может там в настройках ИАР есть переключатели типа "Жутко стандартный ++"/"Для нормальных пацанов" ?

все что можно попробовал, почитал мануал по C/C++ для ИАРа, и ничего.

А память хоть в new выделилась, this не нулевой ?

this не нулевой, но все его элементы нулевые

Вроде как проблема будет, если куча вообще не включена

кучу, стек и все вместе с ними определил...

Сообщение отредактировал A_Sherbakov - Sep 26 2014, 11:34

[den_po]

Версия иара-то какая?

[Сергей Борщ]

Я не знаю, как работает ARP. Поэтому я не знаю, что вы хотели написать в строке " this->ArpLayer = (t_ARPlayer*)data+14;". Возможно вы хотели указателю ArpLayer присвоить адрес 14 байта входного буфера, а на самом деле приваивает адрес 14 * sizeof(t_ARPlayer) -го байта.

[adnega]

Легко проверить путем сравнения значений: адрес data и адрес this->ArpLayer.

[WitFed]

Я бы ещё попробовал вынести определение типа "struct t_ARPlayer{" в более внешнюю область.
Хотя С++-компиляторы и должны поддерживать все современные извраты типа заключения определений типа в структуру и юзанья оттудова в шаблоне, зависящем от этой структуры, хорошо это сделают совсем немногие, а другие могут и треснуть внутри.
"(t_ARPlayer*)data+14", конечно, лучше изложить в редакции "(t_ARPlayer*)(data+14)" -- вряд ли подразумевается 14-я структура.

Ещё есть вариант с подменой оператора new на более свой -- мне наш Плюсолюб подсказал. Вдруг проканает через malloc() взятый кусок.
Память под объект может быть выделена любым методом, только нужно сварганить свои операторы new/delete (placement new) и вызывать их с дополнительным параметром (а обычный new останется -- просто так, без доп-параметра):

Код

void * operator new(size_t, void *ptr) {return ptr;}
void operator delete(void *, void * ptr) {}
eArp *p = (eArp*) malloc(sizeof(eArp));
new (p) eArp(buf);  // call constructor with ready memory
(*p).~eArp(); // call destructor without delete()

[A_Sherbakov]

Всем спасибо за советы, но все оказалось гораздо проще. Куча была определена не по тем адресам. В стандартном файле *.icf куча была засунута на SD-RAM, которая у меня не была подключена.

Код

define symbol __ICFEDIT_region_RAM_start__ = 0x10000000;
define symbol __ICFEDIT_region_RAM_end__   = 0x1000FFDF;

define symbol __region_SDRAM_start__ =  0xA0000000;
define symbol __region_SDRAM_end__    = 0xA3F7FFFF;

/*перенес сюда*/
place in RAM_region   { readwrite,
                        block HEAP, block CSTACK };
place in SDRAM_region { /* (Была определена тут) block HEAP*/ };