как реализуются виртуальные функции и vtable?

<p>мы все знаем, что такое виртуальные функции в c++, но как они реализуются на глубоком уровне?</p><p>может ли vtable быть изменен или даже напрямую доступен во время выполнения?</p><p>существует ли vtable для всех классов или только для тех, у которых есть хотя бы одна виртуальная функция?</p><p>у абстрактных классов просто есть null для указателя на функцию хотя бы одной записи?</p><p>замедляет ли наличие одной виртуальной функции весь класс? или только вызов функции, которая является виртуальной? и влияет ли скорость, если виртуальная функция действительно перезаписана или нет, или это не оказывает влияния, пока она виртуальная.</p>

<h2>как виртуальные функции реализуются на глубоком уровне?</h2><p>from <a href="http://wayback.archive.org/web/20100209040010/http://www.codersource.net/published/view/325/virtual\_functions\_in.aspx">"виртуальные функции в c++"</a> :</p><blockquote> <p>всякий раз, когда в программе объявлена виртуальная функция, для класса создается таблица v. v-таблица состоит из адресов виртуальных функций для классов, которые содержат одну или несколько виртуальных функций. объект класса, содержащий виртуальную функцию, содержит виртуальный указатель, который указывает на базовый адрес виртуальной таблицы в памяти. всякий раз, когда происходит вызов виртуальной функции, v-таблица используется для определения адреса функции. объект класса, который содержит одну или несколько виртуальных функций, содержит виртуальный указатель, называемый vptr, в самом начале объекта в памяти. следовательно, размер объекта в этом случае увеличивается на размер указателя. этот vptr содержит базовый адрес виртуальной таблицы в памяти. обратите внимание, что виртуальные таблицы являются специфическими для класса, то есть существует только одна виртуальная таблица для класса независимо от количества виртуальных функций, которые он содержит. эта виртуальная таблица, в свою очередь, содержит базовые адреса одной или нескольких виртуальных функций класса. в то время, когда виртуальная функция вызывается для объекта, vptr этого объекта предоставляет базовый адрес виртуальной таблицы для этого класса в памяти. эта таблица используется для разрешения вызова функции, так как содержит адреса всех виртуальных функций этого класса. вот как динамическое связывание разрешается во время вызова виртуальной функции.</p> </blockquote><h2>можно ли изменить vtable или даже получить к нему прямой доступ во время выполнения?</h2><p>в целом, я считаю, что ответ "нет". вы могли бы сделать некоторое искажение памяти, чтобы найти vtable, но вы все еще не знали бы, как выглядит сигнатура функции, чтобы вызвать ее. все, чего вы хотели бы достичь с помощью этой возможности (которую поддерживает язык), должно быть возможным без прямого доступа к vtable или его изменения во время выполнения. также обратите внимание, что спецификация языка c++ <strong> не определяет </strong>, что vtables требуются, однако именно так большинство компиляторов реализуют виртуальные функции.</p><h2>существует ли vtable для всех объектов или только для тех, у которых есть хотя бы одна виртуальная функция?</h2><p>я <em> считаю </em> ответ здесь "это зависит от реализации", так как спецификация в первую очередь не требует vtables. однако на практике я считаю, что все современные компиляторы создают vtable только в том случае, если у класса есть хотя бы одна виртуальная функция. с vtable связаны служебные расходы пространства и временные издержки, связанные с вызовом виртуальной функции по сравнению с не виртуальной функцией.</p><h2>у абстрактных классов просто есть null для указателя на функцию хотя бы одной записи?</h2><p>ответ в том, что он не указан спецификацией языка, поэтому зависит от реализации. вызов чисто виртуальной функции приводит к неопределенному поведению, если оно не определено (а обычно это не так) (iso/iec 14882: 2003 10.4-2). на практике он выделяет слот в vtable для функции, но не назначает ей адрес. это оставляет vtable незавершенным, что требует от производных классов реализации функции и завершения vtable. некоторые реализации просто помещают указатель null в запись vtable; другие реализации помещают указатель на фиктивный метод, который делает нечто похожее на утверждение.</p><p>обратите внимание, что абстрактный класс может определять реализацию для чисто виртуальной функции, но эта функция может вызываться только с синтаксисом квалифицированного идентификатора (т. е. полное указание класса в имени метода, аналогично вызову метода базового класса из производный класс). это сделано для обеспечения простой в использовании реализации по умолчанию, но при этом требуется, чтобы производный класс предоставил переопределение.</p><h2>замедляет ли наличие одной виртуальной функции весь класс или только вызов виртуальной функции?</h2><p>это доходит до края моих знаний, поэтому кто-нибудь, пожалуйста, помогите мне здесь, если я ошибаюсь!</p><p>я <em> полагаю </em>, что только функции, которые являются виртуальными в классе, испытывают удар по производительности, связанный с вызовом виртуальной функции по сравнению с не виртуальной функцией. накладные расходы для класса есть в любом случае. обратите внимание, что если существует vtable, то существует только 1 для каждого <em> класса </em>, а не один для <em> объекта </em>.</p><h2>затрагивается ли скорость, если виртуальная функция фактически переопределена или нет, или это не оказывает влияния, пока она виртуальная?</h2><p>я не верю, что время выполнения виртуальной функции, которая переопределена, уменьшается по сравнению с вызовом базовой виртуальной функции. тем не менее, есть дополнительные затраты пространства для класса, связанные с определением другой vtable для производного класса по сравнению с базовым классом.</p><h2>дополнительные ресурсы:</h2><p> <a href="http://wayback.archive.org/web/20100209040010/http://www.codersource.net/published/view/325/virtual\_functions\_in.aspx">http://www.codersource.net/published/view/325/virtual\_functions\_in.aspx</a> (через обратную машину)<br> <a href="http://en.wikipedia.org/wiki/virtual\_table">http://en.wikipedia.org/wiki/virtual\_table</a> <br> <a href="http://www.codesourcery.com/public/cxx-abi/abi.html#vtable">http://www.codesourcery.com/public/cxx-abi/abi.html#vtable</a> </p>

<ul> <li>можно ли изменить vtable или даже получить к нему прямой доступ во время выполнения?</li> </ul><p>не переносимо, но если вы не против грязных уловок, конечно!</p><blockquote> <p><strong>warning</strong>: этот метод не рекомендуется использовать детям, взрослым в возрасте до <a href="https://en.wikipedia.org/wiki/methuselah">969</a> или маленьким пушистым существам от альфы центавра. побочные эффекты могут включать <a href="http://www.catb.org/jargon/html/n/nasal-demons.html">демоны, которые вылетают из вашего носа</a> , внезапное появление <a href="https://en.wikipedia.org/wiki/yog-sothoth">yog-sothoth</a> в качестве обязательного утверждающего во всех последующих проверках кода или ретроактивное добавление - <a href="http://unsongbook.com/interlude-%d7%90-the-cracks-in-the-sky/"><code>ihuman::playpiano()</code></a> для всех существующих экземпляров]</p> </blockquote><p>в большинстве компиляторов, которые я видел, vtbl * - это первые 4 байта объекта, а содержимое vtbl - это просто массив указателей на элементы (обычно в том порядке, в котором они были объявлены, с первым в базовом классе). конечно, есть и другие возможные варианты размещения, но это то, что я обычно наблюдаю.</p><pre><code>class a { public: virtual int f1() = 0; }; class b : public a { public: virtual int f1() { return 1; } virtual int f2() { return 2; } }; class c : public a { public: virtual int f1() { return -1; } virtual int f2() { return -2; } }; a *x = new b; a *y = new c; a *z = new c; </code></pre><p>теперь, чтобы вытащить некоторые махинации ...</p><p>изменение класса во время выполнения:</p><pre><code>std::swap(*(void **)x, *(void **)y); // now x is a c, and y is a b! hope they used the same layout of members! </code></pre><p>замена метода для всех экземпляров (monkeypatching класса)</p><p>это немного сложнее, поскольку сам vtbl, вероятно, находится в постоянной памяти.</p><pre><code>int f3(a*) { return 0; } mprotect(*(void **)x,8,prot\_read|prot\_write|prot\_exec); // or virtualprotect on win32; this part's very os-specific (*(int (***)(a *)x)[0] = f3; // now c::f1() returns 0 (remember we made x into a c above) // so x->f1() and z->f1() both return 0 </code></pre><p>последний, скорее всего, заставит вирус-чекеры и ссылку проснуться и заметить из-за манипуляций с mprotect. в процессе, использующем бит nx, он может потерпеть неудачу.</p>

<h2>замедляет ли наличие одной виртуальной функции весь класс?</h2><blockquote> <p>или только вызов функции, которая является виртуальной? и влияет ли скорость, если виртуальная функция действительно перезаписана или нет, или это не оказывает влияния, пока она виртуальная.</p> </blockquote><p>наличие виртуальных функций замедляет весь класс, поскольку еще один элемент данных должен быть инициализирован, скопирован ... при работе с объектом такого класса. для класса с полдюжиной членов или около того, разница должна быть незначительной. для класса, который содержит только один член <code>char</code> или вообще не содержит членов, разница может быть заметной.</p><p>кроме того, важно отметить, что не каждый вызов виртуальной функции является вызовом виртуальной функции. если у вас есть объект известного типа, компилятор может генерировать код для обычного вызова функции, и даже может встроить указанную функцию, если она на это похожа. только когда вы выполняете полиморфные вызовы, через указатель или ссылку, которые могут указывать на объект базового класса или объект некоторого производного класса, вам требуется косвенное обращение к vtable и оплата за него с точки зрения производительности.</p><pre><code>struct foo { virtual ~foo(); virtual int a() { return 1; } }; struct bar: public foo { int a() { return 2; } }; void f(foo& arg) { foo x; x.a(); // non-virtual: always calls foo::a() bar y; y.a(); // non-virtual: always calls bar::a() arg.a(); // virtual: must dispatch via vtable foo z = arg; // copy constructor foo::foo(const foo&) will convert to foo z.a(); // non-virtual foo::a, since z is a foo, even if arg was not } </code></pre><p>шаги, которые должно предпринять аппаратное обеспечение, по сути одинаковы, независимо от того, переписана ли функция или нет. адрес vtable считывается из объекта, указатель функции извлекается из соответствующего слота, а функция вызывается указателем. с точки зрения фактической производительности прогнозы ветвления могут оказать некоторое влияние. так, например, если большинство ваших объектов ссылаются на одну и ту же реализацию данной виртуальной функции, то есть некоторый шанс, что предиктор ветвления правильно предскажет, какую функцию вызвать, даже до того, как указатель будет получен. но не имеет значения, какая функция является общей: это может быть большинство объектов, делегирующих не перезаписанному базовому случаю, или большинство объектов, принадлежащих одному и тому же подклассу и, следовательно, делегирующих одному и тому же перезаписанному регистру.</p><h2>как они реализуются на глубоком уровне?</h2><p>мне нравится идея jheriko продемонстрировать это с помощью фиктивной реализации. но я бы использовал c, чтобы реализовать что-то похожее на приведенный выше код, чтобы легче было увидеть низкий уровень.</p><h3>родительский класс foo</h3><pre><code>typedef struct foo\_t foo; // forward declaration struct slotsfoo { // list all virtual functions of foo const void *parentvtable; // (single) inheritance void (*destructor)(foo*); // virtual destructor foo::~foo int (*a)(foo*); // virtual function foo::a }; struct foo\_t { // class foo const struct slotsfoo* vtable; // each instance points to vtable }; void destructfoo(foo* self) { } // foo::~foo int afoo(foo* self) { return 1; } // foo::a() const struct slotsfoo vtablefoo = { // only one constant table 0, // no parent class destructfoo, afoo }; void constructfoo(foo* self) { // foo::foo() self->vtable = &vtablefoo; // object points to class vtable } void copyconstructfoo(foo* self, foo* other) { // foo::foo(const foo&) self->vtable = &vtablefoo; // don't copy from other! } </code></pre><h3>производный класс bar</h3><pre><code>typedef struct bar\_t { // class bar foo base; // inherit all members of foo } bar; void destructbar(bar* self) { } // bar::~bar int abar(bar* self) { return 2; } // bar::a() const struct slotsfoo vtablebar = { // one more constant table &vtablefoo, // can dynamic\_cast to foo (void(*)(foo*)) destructbar, // must cast type to avoid errors (int(*)(foo*)) abar }; void constructbar(bar* self) { // bar::bar() self->base.vtable = &vtablebar; // point to bar vtable } </code></pre><h3>функция f, выполняющая вызов виртуальной функции</h3><pre><code>void f(foo* arg) { // same functionality as above foo x; constructfoo(&x); afoo(&x); bar y; constructbar(&y); abar(&y); arg->vtable->a(arg); // virtual function call foo z; copyconstructfoo(&z, arg); afoo(&z); destructfoo(&z); destructbar(&y); destructfoo(&x); } </code></pre><p>итак, вы можете видеть, что vtable - это просто статический блок в памяти, в основном содержащий указатели на функции. каждый объект полиморфного класса будет указывать на vtable, соответствующий его динамическому типу. это также делает связь между rtti и виртуальными функциями более ясной: вы можете проверить, к какому типу относится класс, просто посмотрев, на какую vtable он указывает. вышеуказанное упрощается во многих отношениях, например, множественное наследование, но общая концепция обоснована.</p><p>если <code>arg</code> имеет тип <code>foo*</code> и вы берете <code>arg->vtable</code>, но на самом деле является объектом типа <code>bar</code>, тогда вы все равно получите правильный адрес <code>vtable</code>. это потому, что <code>vtable</code> всегда является первым элементом по адресу объекта, независимо от того, называется ли он <code>vtable</code> или <code>base.vtable</code> в правильно набранном выражении.</p>

<p>вот <strong>runnable</strong> ручная реализация виртуальной таблицы в современном c++. у него четко определенная семантика, нет хаков и нет <code>void*</code>.</p><p>примечание. <code>.*</code> и <code>->*</code> - это разные операторы, чем <code>*</code> и <code>-></code>. указатели на функции-члены работают по-разному.</p><pre><code>#include <iostream> #include <vector> #include <memory> struct vtable; // forward declare, we need just name class animal { public: const std::string& get\_name() const { return name; } // these will be abstract bool has\_tail() const; bool has\_wings() const; void sound() const; protected: // we do not want animals to be created directly animal(const vtable* vtable\_ptr, std::string name) : vtable\_ptr(vtable\_ptr), name(std::move(name)) { } private: friend vtable; // just in case for non-public methods const vtable* const vtable\_ptr; std::string name; }; class cat : public animal { public: cat(std::string name); // functions to bind dynamically bool has\_tail() const { return true; } bool has\_wings() const { return false; } void sound() const { std::cout << get\_name() << " does meow\n"; } }; class dog : public animal { public: dog(std::string name); // functions to bind dynamically bool has\_tail() const { return true; } bool has\_wings() const { return false; } void sound() const { std::cout << get\_name() << " does whoof\n"; } }; class parrot : public animal { public: parrot(std::string name); // functions to bind dynamically bool has\_tail() const { return false; } bool has\_wings() const { return true; } void sound() const { std::cout << get\_name() << " does crrra\n"; } }; // now the magic - pointers to member functions! struct vtable { bool (animal::* const has\_tail)() const; bool (animal::* const has\_wings)() const; void (animal::* const sound)() const; // constructor vtable ( bool (animal::* const has\_tail)() const, bool (animal::* const has\_wings)() const, void (animal::* const sound)() const ) : has\_tail(has\_tail), has\_wings(has\_wings), sound(sound) { } }; // global vtable objects const vtable vtable\_cat( static\_cast<bool (animal::*)() const>(&cat::has\_tail), static\_cast<bool (animal::*)() const>(&cat::has\_wings), static\_cast<void (animal::*)() const>(&cat::sound)); const vtable vtable\_dog( static\_cast<bool (animal::*)() const>(&dog::has\_tail), static\_cast<bool (animal::*)() const>(&dog::has\_wings), static\_cast<void (animal::*)() const>(&dog::sound)); const vtable vtable\_parrot( static\_cast<bool (animal::*)() const>(&parrot::has\_tail), static\_cast<bool (animal::*)() const>(&parrot::has\_wings), static\_cast<void (animal::*)() const>(&parrot::sound)); // set vtable pointers in constructors cat::cat(std::string name) : animal(&vtable\_cat, std::move(name)) { } dog::dog(std::string name) : animal(&vtable\_dog, std::move(name)) { } parrot::parrot(std::string name) : animal(&vtable\_parrot, std::move(name)) { } // implement dynamic dispatch bool animal::has\_tail() const { return (this->*(vtable\_ptr->has\_tail))(); } bool animal::has\_wings() const { return (this->*(vtable\_ptr->has\_wings))(); } void animal::sound() const { (this->*(vtable\_ptr->sound))(); } int main() { std::vector<std::unique\_ptr<animal>> animals; animals.push\_back(std::make\_unique<cat>("grumpy")); animals.push\_back(std::make\_unique<cat>("nyan")); animals.push\_back(std::make\_unique<dog>("doge")); animals.push\_back(std::make\_unique<parrot>("party")); for (const auto& a : animals) a->sound(); // note: destructors are not dispatched virtually } </code></pre>

<p>я постараюсь сделать это просто :)</p><h2>мы все знаем, что такое виртуальные функции в c++, но как они реализуются на глубоком уровне?</h2><p>это массив с указателями на функции, которые являются реализациями конкретной виртуальной функции. индекс в этом массиве представляет конкретный индекс виртуальной функции, определенной для класса. это включает в себя чисто виртуальные функции.</p><p>когда полиморфный класс наследуется от другого полиморфного класса, у нас могут быть следующие ситуации:</p><ul> <li>производный класс не добавляет новые виртуальные функции и не переопределяет их. в этом случае этот класс делит виртуальную таблицу с базовым классом.</li> <li>производный класс добавляет и переопределяет виртуальные методы. в этом случае он получает свой собственный vtable, где добавленные виртуальные функции имеют индекс, начинающийся после последней производной.</li> <li>множественные полиморфные классы в наследстве. в этом случае мы имеем сдвиг индекса между вторым и следующим основами и его индекс в производном классе</li> </ul><h2>можно ли изменить vtable или даже получить к нему прямой доступ во время выполнения?</h2><p>нестандартный способ - нет api для доступа к ним. компиляторы могут иметь некоторые расширения или частные api для доступа к ним, но это может быть только расширение.</p><h2>существует ли vtable для всех классов или только для тех, у которых есть хотя бы одна виртуальная функция?</h2><p>только те, которые имеют по крайней мере одну виртуальную функцию (будь то деструктор) или получают по крайней мере один класс, у которого есть vtable ("полиморфный").</p><h2>у абстрактных классов просто есть null для указателя на функцию хотя бы одной записи?</h2><p>это возможная реализация, а не практиковалось. вместо этого обычно есть функция, которая печатает что-то вроде "чисто виртуальная функция называется" и выполняет <code>abort()</code>. это может произойти, если вы попытаетесь вызвать абстрактный метод в конструкторе или деструкторе.</p><h2>замедляет ли наличие одной виртуальной функции весь класс? или только вызов функции, которая является виртуальной? и влияет ли скорость, если виртуальная функция действительно перезаписана или нет, или это не оказывает влияния, пока она виртуальная.</h2><p>замедление зависит только от того, разрешен ли вызов как прямой или виртуальный. и больше ничего не имеет значения. :)</p><p>если вы вызываете виртуальную функцию через указатель или ссылку на объект, то она всегда будет реализована как виртуальный вызов - потому что компилятор никогда не может знать, какой тип объекта будет назначен этому указателю во время выполнения, и является ли он объектом класс, в котором этот метод переопределен или нет. только в двух случаях компилятор может разрешить вызов виртуальной функции как прямой вызов:</p><ul> <li>если вы вызываете метод через значение (переменную или результат функции, которая возвращает значение) - в этом случае компилятор не сомневается в фактическом классе объекта и может "жестко разрешить" его во время компиляции ,.</li> <li>если виртуальный метод объявлен <code>final</code> в классе, к которому у вас есть указатель или ссылка, через которую вы вызываете его (<strong>только в c++ 11</strong>). в этом случае компилятор знает, что этот метод не может быть переопределен и может быть только методом из этого класса.</li> </ul><p>обратите внимание, что для виртуальных вызовов требуется только разыменование двух указателей. использование rtti (хотя доступно только для полиморфных классов) медленнее, чем вызов виртуальных методов, если вы обнаружите, что нужно реализовать одно и то же двумя способами. например, определение <code>virtual bool hashoof() { return false; }</code> и затем переопределение только как <code>bool horse::hashoof() { return true; }</code> предоставит вам возможность вызывать <code>if (anim->hashoof())</code>, что будет быстрее, чем попытка <code>if(dynamic\_cast<horse*>(anim))</code>. это связано с тем, что <code>dynamic\_cast</code> в некоторых случаях должен проходить по иерархии классов, даже рекурсивно, чтобы выяснить, можно ли построить путь из фактического типа указателя и требуемого типа класса. при этом виртуальный вызов всегда один и тот же - разыменование двух указателей.</p>

<p>этот ответ был включен в <a href="https://stackoverflow.com/questions/99297/at-as-deep-of-a-level-as-possible-how-are-virtual-functions-implemented#99341">community wiki answer</a> </p><ul> <li><strong> у абстрактных классов просто null для указателя функции хотя бы на одну запись? </strong></li> </ul><p>ответ на этот вопрос заключается в том, что она не определена - вызов чистой виртуальной функции приводит к неопределенному поведению, если оно не определено (а обычно это не так) (iso/iec 14882: 2003 10.4-2). некоторые реализации просто помещают указатель null в запись vtable; другие реализации помещают указатель на фиктивный метод, который делает нечто похожее на утверждение.</p><p>обратите внимание, что абстрактный класс может определять реализацию для чисто виртуальной функции, но эту функцию можно вызывать только с синтаксисом квалифицированного идентификатора (т. е. с полным указанием класса в имени метода, аналогично вызову метода базового класса из производный класс). это сделано для обеспечения простой в использовании реализации по умолчанию, но при этом требуется, чтобы производный класс предоставил переопределение.</p>

<p>вы можете воссоздать функциональность виртуальных функций в c++, используя указатели функций в качестве членов класса и статические функции в качестве реализаций, или используя указатель на функции-члены и функции-члены для реализаций. между этими двумя методами есть только нотационные преимущества ... фактически вызовы виртуальных функций сами по себе являются просто нотационным удобством. на самом деле наследование - это просто обозначение удобства ... все это может быть реализовано без использования языковых возможностей для наследования. :)</p><p>ниже не проверено, возможно, глючный код, но, надеюсь, демонстрирует идею.</p><p>например.</p><pre><code>class foo { protected: void(*)(foo*) myfunc; public: foo() { myfunc = 0; } void replciatedvirtualfunctioncall() { myfunc(*this); } ... }; class bar : public foo { private: static void impl1(foo* f) { ... } public: bar() { myfunc = impl1; } ... }; class baz : public foo { private: static void impl2(foo* f) { ... } public: baz() { myfunc = impl2; } ... }; </code></pre>

<p>обычно с vtable, массивом указателей на функции.</p>

<p>во всех этих ответах здесь не упоминается то, что в случае множественного наследования все базовые классы имеют виртуальные методы. унаследованный класс имеет несколько указателей на vmt. в результате размер каждого экземпляра такого объекта больше. всем известно, что у класса с виртуальными методами есть 4 байта дополнительно для vmt, но в случае множественного наследования это для каждого базового класса, у которого есть виртуальные методы, умноженные на 4. 4 - размер указателя.</p>

<p>каждый объект имеет указатель vtable, который указывает на массив функций-членов.</p>

<p>очень милое доказательство концепции, которое я сделал немного раньше (чтобы увидеть, имеет ли значение порядок наследования); дайте мне знать, если ваша реализация c++ фактически отвергает ее (моя версия gcc дает только предупреждение о назначении анонимных структур, но это ошибка), мне любопытно.</p><p><strong>ccpolite.h</strong>:</p><pre><code>#ifndef ccpolite\_h #define ccpolite\_h /* the vtable or interface */ typedef struct { void (*greet)(void *); void (*thank)(void *); } iccpolite; /** * the actual "object" literal as c++ sees it; public variables be here too * all cpolite objects use(are instances of) this struct's structure. */ typedef struct { iccpolite *vtbl; } cpolite; #endif /* ccpolite\_h */ </code></pre><p><strong>ccpolite\_constructor.h</strong>:</p><pre><code>/** * unconventionally include me after defining object\_name to automate * static(allocation-less) construction. * * note: i assume cpolite\_h is included; since if i use anonymous structs * for each object, they become incompatible and cause compile time errors * when trying to do stuff like assign, or pass functions. * this is similar to how you can't pass void * to windows functions that * take handles; these handles use anonymous structs to make * hwnd/handle/hinstance/void*/etc not automatically convertible, and * require a cast. */ #ifndef object\_name #error ccpolite> constructor requires object name. #endif cpolite object\_name = { &ccpolite\_vtbl }; /* ensure no global scope pollution */ #undef object\_name </code></pre><p><strong>main.c</strong>:</p><pre><code>#include <stdio.h> #include "ccpolite.h" // | a greeter is capable of greeting; nothing else. struct igreeter { virtual void greet() = 0; }; // | a thanker is capable of thanking; nothing else. struct ithanker { virtual void thank() = 0; }; // | a polite is something that implements both igreeter and ithanker // | note that order of implementation does matter. struct ipolite1 : public igreeter, public ithanker{}; struct ipolite2 : public ithanker, public igreeter{}; // | implementation if ipolite1; implements igreeter before ithanker struct cpolite1 : public ipolite1 { void greet() { puts("hello!"); } void thank() { puts("thank you!"); } }; // | implementation if ipolite1; implements ithanker before igreeter struct cpolite2 : public ipolite2 { void greet() { puts("hi!"); } void thank() { puts("ty!"); } }; // | imposter polite's greet implementation. static void ccpolite\_greet(void *) { puts("hi i am c!!!!"); } // | imposter polite's thank implementation. static void ccpolite\_thank(void *) { puts("thank you, i am c!!"); } // | vtable of the imposter polite. iccpolite ccpolite\_vtbl = { ccpolite\_thank, ccpolite\_greet }; cpolite ccpoliteobj = { &ccpolite\_vtbl }; int main(int argc, char **argv) { puts("\npart 1"); cpolite1 o1; o1.greet(); o1.thank(); puts("\npart 2"); cpolite2 o2; o2.greet(); o2.thank(); puts("\npart 3"); cpolite1 *not1 = (cpolite1 *)&o2; cpolite2 *not2 = (cpolite2 *)&o1; not1->greet(); not1->thank(); not2->greet(); not2->thank(); puts("\npart 4"); cpolite1 *fake = (cpolite1 *)&ccpoliteobj; fake->thank(); fake->greet(); puts("\npart 5"); cpolite2 *fake2 = (cpolite2 *)fake; fake2->thank(); fake2->greet(); puts("\npart 6"); #define object\_name fake3 #include "ccpolite\_constructor.h" fake = (cpolite1 *)&fake3; fake->thank(); fake->greet(); puts("\npart 7"); #define object\_name fake4 #include "ccpolite\_constructor.h" fake2 = (cpolite2 *)&fake4; fake2->thank(); fake2->greet(); return 0; } </code></pre><p>результат:</p><pre><code>part 1 hello! thank you! part 2 hi! ty! part 3 ty! hi! thank you! hello! part 4 hi i am c!!!! thank you, i am c!! part 5 thank you, i am c!! hi i am c!!!! part 6 hi i am c!!!! thank you, i am c!! part 7 thank you, i am c!! hi i am c!!!! </code></pre><p>обратите внимание, поскольку я никогда не выделяю свой поддельный объект, нет необходимости делать какие-либо уничтожения; деструкторы автоматически помещаются в конец области видимости динамически размещаемых объектов, чтобы восстановить память самого литерала объекта и указателя vtable.</p>

<p>ответы берли здесь верны, за исключением вопроса:</p><p><em>у абстрактных классов просто null для указателя на функцию хотя бы одной записи?</em></p><p>ответ в том, что для абстрактных классов виртуальная таблица вообще не создается. в этом нет необходимости, поскольку объекты этих классов не могут быть созданы!</p><p>другими словами, если у нас есть:</p><pre><code>class b { ~b() = 0; }; // abstract base class class d : public b { ~d() {} }; // concrete derived class d* pd = new d(); b* pb = pd; </code></pre><p>указатель vtbl, доступ к которому осуществляется через pb, будет vtbl класса d. именно так реализуется полиморфизм. то есть, как к методам d обращаются через pb. нет необходимости в vtbl для класса b.</p><h2>в ответ на комментарий майка ниже ...</h2><p>если у класса b в моем описании есть виртуальный метод <em>foo ()</em>, который не переопределяется d, и виртуальный метод <em>bar ()</em>, который переопределяется, то у vtbl d будет указатель на b's <em>foo ()</em> и на собственный <em>bar ()</em>. там еще нет vtbl, созданный для b.</p>