Объектная модель G ++

Сегодня я прочитал <>. Я столкнулся с проблемой. Как говорится в книге,

class Concrete1 {
public:
int val;
char bit1;
};

class Concrete2 : public Concrete1 {
public:
char bit2;
};

class Concrete3 : public Concrete2 {
public:
char bit3;
};

когда я запускаю код в mingw g ++, пространство трех классов составляет 8, 12, 12. Но когда я запускаю код в vs2012, пространство трех классов составляет 8, 12, 16. Конечно, код в vs2012 без проблем. Но что касается пространства в g ++, у меня есть несколько вопросов, и я пытаюсь написать пример кода, чтобы увидеть, есть ли проблема. Пример кода выглядит следующим образом:

int main(void)
{
Concrete2 con2;
memset(&con2, 0, sizeof(con2));
Concrete3  con3;
con3.val = 3;
con3.bit2 =  4;
con3.bit3 = 5;
Concrete2* con_ptr2 = &con2;
Concrete2* con_ptr3 = &con3;
*con_ptr3 = *con_ptr2;
cout << con3.bit3<< endl;
cout << sizeof(Concrete1) << endl;
cout << sizeof(Concrete2) << endl;
cout << sizeof(Concrete3) << endl;
return 0;
}

и для объектной модели в g ++, код без проблем. Почему после кода «* con_ptr3 = * con_ptr2;», con3.bit3 равен 5, а не 0?
Может кто-нибудь мне помочь ?

0

Решение

Кажется, что результат правильный, бит 3 должен быть 5, потому что это назначение влияет только на части Concrete1 и Concrete2 con3.

Назначение является членским, а не побайтовым.
Таким образом, «* com_ptr3 = * con_ptr2» отличается от «memcpy (con_ptr3, con_ptr2, sizeof (Concrete2))». Конструктор копирования по умолчанию и операторы присваивания по умолчанию должны копировать данные по элементам и в порядке, в котором элементы определены в класс.
Это также означает, что вы не можете рассчитывать на байты заполнения, имеющие какое-либо конкретное значение.

Разница в размерах только потому, что VS и GCC обрабатывают отступы немного по-разному.
Очевидно, что gcc может упаковывать биты 2 и 3 в одно и то же 32-битное слово, а VS — нет.
Странно, что gcc также не может упаковать бит 1, что приводит к размерам 8,8,8.

Это может быть потому, что gcc считает Concrete1 POD, а Concrete 2 и 3 — нет. Стандарт предъявляет более строгие требования к расположению данных в типах POD по сравнению с не-pod. Компилятор обладает большей гибкостью в расположении данных класса для типов, не относящихся к модулю.

0

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]