Почему множественное наследование увеличивает размер объекта, несмотря на то, что базы пустые?

С учетом этого кода:

#include <iostream>

struct A {

};

struct B {

};

struct C {

};

struct E : A {
    int field;
};

struct F : A, B {
    int field;
};

struct G : A, B, C {
    int field;
};

int main() {
    std::cout << _MSC_VER << std::endl;
    std::cout << sizeof(E) << std::endl;
    std::cout << sizeof(F) << std::endl;
    std::cout << sizeof(G) << std::endl;
    int o;
    std::cin >> o;
    return 0;
}

Мне дается следующий вывод:

1900
4
8
8

Почему F и G имеют размеры 8, хотя их базы пустые? И почему размер E также не увеличивается?

Я создаю это с помощью Visual Studio Community 2015, версия 14.0.25431.01. Обновление 3. Версия MSVС++, по-видимому, 9.0.

Как получилось? Какое обоснование существует для такого своеобразного макета памяти?

Ответы

Ответ 1

Обновление Visual Studio 2015 2 добавило поддержку для оптимизации пустого базового класса. Однако, поскольку обновления должны быть совместимы с макетами, оптимизация не включена по умолчанию; вам необходимо вручную запросить его с помощью __declspec (empty_bases).

Там больше информации в блоге VC: https://blogs.msdn.microsoft.com/vcblog/2016/03/30/optimizing-the-layout-of-empty-base-classes-in-vs2015-update-2-3/

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

Ответ 2

Не существует языкового правила, в котором говорится, что любой конкретный тип должен иметь какой-либо конкретный размер, за исключением char (размер 1), и подчиняться ограничению, что объекты объекта класса имеют ненулевой размер. Нет ничего плохого в вашем конкретном способе компиляции для размещения типов в вашем примере.

Что касается нового вопроса, после того, как вы его отредактировали: возможно, что MSVC просто не прикладывает много усилий для оптимизации множественного наследования, потому что это сравнительно редко, что вы можете утверждать, что там мало окупаемости. Я ничего не знаю о процессе принятия реальных решений, но просто подумайте, что в игре могут быть прагматические технические компромиссы.