Я думаю, все знают, что такое наследование или хотя бы слышали о нём. Часто мы используем наследование ради полиморфного поведения объектов. Но задумываемся ли мы о той цене, которую приходится платить за виртуальность? Поставлю вопрос по-другому: каждый ли знает эту цену? Давайте попробуем разобраться в этой проблеме.


В общем случае, выглядит наследование так:

class Base
{
    int variable;
};

class Child: public Base
{

};

При этом, как мы прекрасно знаем, класс Сhild наследует все члены класса Base. Т.е. с точки зрения размеров объектов, сейчас у нас sizeof(Base) = sizeof(Child) и составляет 4 (поскольку sizeof(int) = 4).

Не помешает сразу напомнить, что такое выравнивание. У нас есть два класса:

class A1
{
    int iv;
    double dv;
    int iv2;
};

class A2
{
    double dv;
    int iv;
    int iv2;
};

Вроде бы они ничем не отличаются друг от друга. Однако их размеры не одинаковы: sizeof(A2) = 16, sizeof(A1) = 24.

Всё дело в расположении переменных внутри класса. Если они имеют разный тип, то их расположение может серьёзно повлиять на размер объекта. В данном случае sizeof(double = 8), т.е 8 + 4 + 4 = 16, но класс A1 при этом имеет больший размер. А всё потому, что:



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


Но, скорее всего, вы и так это знали.

Теперь давайте вспомним, как мы расплачиваемся за виртуальные функции в классе. Вы, возможно, помните о таблицах виртуальных методов. Стандарт С++ не предусматривает какой-то единой реализации для вычисления адреса функции во время выполнения. Всё сводится к тому, что у нас появляется указатель в каждом классе, где есть хотя бы одна виртуальная функция.

Давайте допишем одну виртуальную функцию классу Base и посмотрим, как изменятся размеры:

class Base
{
    int variable;
    virtual void f() {}
};

class Child: public Base
{

};

Размер стал равным 16. 8 — размер указателя 4 — int плюс выравнивание. В 32-х разрядной архитектуре размер будет равен 8. 4 — указатель + 4 int без выравнивания.

Чтобы вам не приходилось верить на слово, приводим код, который сгенерировал Hopper Disassembler v4:

//исходный код

class Base
{
    public:
    int variable;
    virtual void f() {}
    Base(): variable(10) {}
};

//в main
Base a;

Ассемблерный код:

 ; Variables:
        ;    var_8: -8


                     __ZN4BaseC2Ev:        // Base::Base()
0000000100000f70         push       rbp                                      ; CODE XREF=__ZN4BaseC1Ev+16
0000000100000f71         mov        rbp, rsp
0000000100000f74         mov        rax, qword [0x100001000]
0000000100000f7b         add        rax, 0x10
0000000100000f7f         mov        qword [rbp+var_8], rdi
0000000100000f83         mov        rdi, qword [rbp+var_8]
0000000100000f87         mov        qword [rdi], rax
0000000100000f8a         mov        dword [rdi+8], 0xa
0000000100000f91         pop        rbp
0000000100000f92         ret

Без виртуальной функции ассемблерный код выглядит так:

 ; Variables:
        ;    var_8: -8


                     __ZN4BaseC2Ev:        // Base::Base()
0000000100000fa0         push       rbp                                     ; CODE XREF=__ZN4BaseC1Ev+16
0000000100000fa1         mov        rbp, rsp
0000000100000fa4         mov        qword [rbp+var_8], rdi
0000000100000fa8         mov        rdi, qword [rbp+var_8]
0000000100000fac         mov        dword [rdi], 0xa
0000000100000fb2         pop        rbp
0000000100000fb3         ret

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

Для тех, кто не любит ассемблер, давайте выведем, как это примерно будет выглядеть в памяти:

#include <iostream>
#include <iomanip>

using namespace std;

const int memorysize = 16;

class Base
{
    public:
    int variable;
    //virtual void f() {}
    Base(): variable(0xAAAAAAAA) {} //чтобы было видно занятое место этой переменной
};

class Child: public Base
{

};

void PrintMemory(const unsigned char memory[])
{
  
  for (size_t i = 0; i < memorysize / 8; ++i) 
  {
    for (size_t j = 0; j < 8; ++j)
    {
      cout << setw(2) << setfill('0') << uppercase << hex
           << (int)(memory[i * 8 + j]) << " ";
    }
    cout << endl;
  }
}

int main()
{
   
   unsigned char memory[memorysize];
   memset(memory, 0xFF, memorysize * sizeof(unsigned char)); //заполняем память мусором FF
   new (memory) Base; //выделяем память на объект и записываем в memory
   PrintMemory(memory);
   reinterpret_cast<Base *>(memory)->~Base();
   
   return 0;
}

Вывод:

AA  AA  AA  AA  FF  FF  FF  FF 
FF   FF   FF   FF   FF  FF  FF  FF

Раскомментим виртуальную функцию и полюбуемся на результат:

E0   30    70   01   01   00  00  00 
AA  AA  AA  AA  FF  FF  FF  FF 

Теперь, когда мы это всё вспомнили, поговорим о виртуальном наследовании. Ни для кого не секрет, что в С++ возможно множественное наследование. Это мощная функция, которую лучше не трогать неумелыми руками — это не приведёт ни к чему хорошему. Но не будем о грустном. Самая известная проблема при множественном наследовании — это проблема ромба.

class A;
class B: public A;
class C: public A;
class D: public B, public C;

В классе D мы получим дублирующиеся члены класса А. Что в этом плохого? Даже если не брать в расчет, что размер класса увеличится на лишние n байт размера класса А, плохо то, что у нас получаются неоднозначности при вызове функций класса А — непонятно, какие именно вызывать: B::A::func или C::A::func. Мы всегда можем устранить подобные неоднозначности явными вызовами, но это не очень удобно. Вот здесь-то в игру и вступает виртуальное наследование. Чтобы не получать дубликат класса А, мы виртуально наследуемся от него:

class A;
class B: public virtual A;
class C: public virtual A;
class D: public B, public C;

Теперь всё хорошо. Или нет? Какой размер будет у класса D, если у нас в классе А всего один виртуальный метод?

cout << sizeof(A) << " " << sizeof(B) << " " 
        << sizeof(C) << " " << sizeof(D) << endl; 

Это интересный вопрос, потому тут всё что зависит от компилятора. Например, Visual Studio 2015 с настройками проекта по умолчанию выдаст: 4 8 8 12.

То есть мы имеем 4 байта на указатель в классе А (далее я буду сокращенно обозначать эти указатели, например, vtbA), дополнительно 4 байта на указатель из-за виртуального наследования для класса B и С (vtbB и vtbC). Наконец в D: 8 + 8 — 4, так как vtbA не дублируется, выходит 12.

А вот gcc 4.2.1 выдаст 8 8 8 16.

Давайте рассмотрим сначала случай без виртуального наследования, потому что результат будет таким же.

8 байт на vtbA, в классах B и С хранятся указатели только на виртуальные таблицы этих классов. Получается, что мы дублируем виртуальные таблицы, но зато не надо хранить vtbA в наследниках. В классе D хранится два адреса: для vtbB и vtbC.

0000000100000f7f         mov        rax, qword [0x100001018]
0000000100000f86         mov        rdi, rax
0000000100000f89         add        rdi, 0x28
0000000100000f8d         add        rax, 0x10
0000000100000f91         mov        rcx, qword [rbp+var_10]
0000000100000f95         mov        qword [rcx], rax
0000000100000f98         mov        qword [rcx+8], rdi
0000000100000f9c         add        rsp, 0x10

…
0000000100001018         dq         0x00000001000010a8                         
…

                     __ZTV1D:        // vtable for D
00000001000010a8         db  0x00 ; '.'                                         ; DATA XREF=0x100001018
...
00000001000010b0         dq         __ZTI1D
00000001000010b8         db  0xc0 ; '.'
...
00000001000010c8         dq         __ZTI1D
00000001000010d0         db  0xc0 ; '.'
…

Ничего не понятно? Смотрите: мы сохраняем два адреса в 0f95 и 0f98. Рассчитываются они исходя из того адреса, что лежит в 1018, плюс 0x28 в первом случае и 0x10 во втором. Итого мы получаем 10b0 и 10d0.

Теперь рассмотрим случай, когда наследование виртуальное.

В плане ассемблерного кода мало что меняется, у нас также хранится два адреса, но виртуальные таблицы для B, C и D стали значительно больше. Например, таблица для класса D увеличилась более чем в 7 раз!

Сэкономили на размере объекта, но увеличили размеры таблиц. А что если мы будем использовать виртуальное наследование повсюду, как советуют некоторые авторы?

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

Итак, начинаем следовать совету в лоб:

class A;
class B: public virtual A;
class C: public virtual A;
class D: public virtual B, public virtual C;

Насколько изменится размер D?

Visual Studio 2015 выведет 4 8 8 16, т. е. добавился еще один указатель в классе D. Путём экспериментов мы выяснили, что, если наследоваться виртуально от каждого класса, то студия добавит еще один указатель в текущий класс. Например, если бы мы написали так:

class D: public virtual B, public C;

или так:

class D: public B, public virtual C;

то размер остался бы 12 байт.

Не подумайте, что студия экономит память, это вовсе не так. Для стандартных настроек размер указателя 4 байта, а не 8, как в gcc. Так что умножайте результат на 2.

А что gcc 4.2.1? Он вообще не изменит размер объектов, вывод все тот же — 8 8 8 16. Но представляете, что стало с таблицей для D?!

На самом деле, она, конечно, увеличилась, но незначительно. Другой вопрос, как это всё повлияет на последующие иерархии.

В качестве чистого эксперимента (не будем думать, есть ли в этом практическая польза) проверим, что случится с такой иерархией:

class A
{
    virtual void func() {}

};

class B: public virtual A
{

};

class C: public virtual A
{

};

class D: public virtual B, public virtual C
{

};

class E: public virtual B, public virtual C, public virtual D
{

};

В студии размер класса E возрастет на 4, это мы уже выяснили, а в gcc размер D и E составит 16 байт.

Но при этом размер виртуальной таблицы для класса E (а она и так немаленькая, если убрать все виртуальное наследование) возрастёт в 4 раза! Если я правильно всё посчитал, то он уже достигнет половины килобайта или около того.

Какой же вывод можно сделать? Такой же, как и раньше: множественное наследование стоит использовать очень аккуратно, виртуальное наследование не панацея и, так или иначе, мы за него расплачиваемся. Возможно, стоит подумать в сторону интерфейсов и отказаться от виртуального наследования вообще.