Влияет ли использование __declspec (novtable) на абстрактные базовые классы каким-либо образом на RTTI? - PullRequest
11 голосов
/ 26 ноября 2009

Или есть ли другие известные негативные последствия использования __declspec (novtable)? Я не могу найти ссылки на какие-либо вопросы.

Ответы [ 2 ]

10 голосов
/ 03 декабря 2009

MSCV использует one vptr per object and one vtbl per class для реализации механизма OO, такого как RTTI и виртуальные функции.
Таким образом, RTTI и виртуальные функции будут работать нормально тогда и только тогда, когда vptr был установлен правильно.

struct __declspec(novtable) B {
    virtual void f() = 0;
};
struct D1 : B {
    D1() {
    }       // after the construction of D1, vptr will be set to vtbl of D1.
};
D1 d1;      // after d has been fully constructed, vptr is correct.
B& b = d1;  // so virtual functions and RTTI will work.
b.f();      // calls D1::f();
assert( dynamic_cast<D1*>(&b) );
assert( typeid(b) == typeid(D1) );

B должен быть абстрактным классом при использовании __declspec(novtable).
Там не будет никакого экземпляра B, кроме как в конструкторе D1.
И __declspec (novtable) в большинстве случаев не оказывает отрицательного влияния.

Но при создании производного класса __declspec(novtable) будет отличать его от семантики ISO C ++.

struct D2 : B {


    D2() {  // when enter the constructor of D2 \  
            //     the vtpr must be set to vptr of B \
            //     if  B didn't use __declspec(novtable).
            // virtual functions and RTTI will also work.

            this->f(); // should calls B::f();
            assert( typeid(*this) == typeid(B) );
            assert( !dynamic_cast<D2*>(this) );
            assert( dynamic_cast<B*>(this) );

            // but __declspec(novtable) will stop the compiler \
            //    from generating code to initialize the vptr.
            // so the code above will crash because of uninitialized vptr.
    }
};

Примечание: виртуальный f () = 0; делает f pure virtual function и B абстрактным классом.
definition чисто виртуальной функции could (не must) отсутствует.
C ++ допускает вызов виртуальной функции в конструкторе, который мы не рекомендуем.

Обновление: Ошибка в D2: vptr в производном конструкторе.

struct D3 : B {  // ISO C++ semantic
    D3() {       // vptr must be set to vtbl of B before enter
    }            // vptr must be set to vtbl of D2 after leave
};

Но vptr не определен во время конструирования. Это одна из причин, по которой виртуальные вызовы функций в конструкторе не рекомендуются.

Если vptr в D2 :: D2 () был B, а определение B :: f () отсутствовало, this->f(); завершится сбоем при разыменовании указателя на функцию в vtbl.
Если vptr в D2 :: D2 () был B и B использует novtable, this->f(); завершится сбоем при разыменовании неинициализированного vptr.

Фактически, vptr в D2 :: D2 () - это D2 в MSVC (msvc8). Компилятор установил vptr в D2 перед выполнением другого кода в D2 :: D2 ().
Так что this->f(); вызывает D2 :: f () и три утверждения будут нарушены.

3 голосов
/ 23 февраля 2011

если я правильно понимаю: Любой виртуальный вызов fn внутри ctor или dtor преобразуется в соединение во время компиляции. Мы не можем делать виртуальные вызовы FN из (c / d) торов. Причина в том, что в момент создания объекта базового класса он не знает производного класса и, следовательно, не может сделать вызов производного класса и w.r.t dtors, к которым применяется та же логика.

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