vtable

As I understand how RTTI is implemented in various C++ compilers (such as GCC), a pointer to the type_info data is stored in the vtable data of each class. And also as mentioned here , POD type may not have a vtable . But if POD types may not have a vtable then where is the pointer to the type_info stored? I know it is implementation-specific, but it would be better to be aware of a C++ compiler (such as GCC) internals. Nicol Bolas There are two kinds of types (for the purposes of RTTI): polymorphic types and non-polymorphic types. A polymorphic type is a type that has a virtual function, in

There is this code: #include <iostream> class Base { int x; }; class Derived : virtual public Base { int y; }; int main() { std::cout << sizeof(Derived) << std::endl; // prints 12 return 0; } I have read that when some class is virtually inherited then there is created empty vtable for class Derived, so memory layout is as follows: Derived::ptr to empty vtable Derived::y Base::x and it is 12 bytes. The question is - what is purpose of this empty vtable if there are not any virtual methods and how is it used? Derived needs some way to know where the Base subobject is. With virtual inheritance,

When compiling with g++, -fdump-class-hierarchy exports the program's vtables in a (more or less) human-readable format. However, the resulting file only contains information about the vtable but not about the class layout itself. I'd like to get a comprehensive list of the layout of all my program's classes. clang offers the -cc1 -fdump-record-layouts arguments to achieve this. The MS compiler can be called using -d1reportAllClassLayout. Is there any g++ switch that does this? If the program is compiled with debugging information, you can use pahole to dump the struct and vtable layouts from

What causes "java.lang.IncompatibleClassChangeError: vtable stub"? In our application, we have seen this error pop up randomly and very seldom (just twice so far, and we run it a lot). It is not readily reproducible, even when restarting the app, using the same jvm/jars without rebuilding. As for our build process, we clean all classes/jars and rebuild them, so it's not the same problem as others have encountered where they made a change in one class and didn't recompile some other dependent classes. This is unlike some of the other questions related to IncompatibleClassChangeError -- none of

I am little confused about vptr and representation of objects in the memory, and hope you can help me understand the matter better. Consider B inherits from A and both define virtual functions f() . From what I learned the representation of an object of class B in the memory looks like this: [ vptr | A | B ] and the vtbl that vptr points to contains B::f() . I also understood that casting the object from B to A does nothing except ignoring the B part at the end of the object. Is it true? Doesn't this behavior is wrong? We want that object of type A to execute A::f() method and not B::f() . Are

I am trying to make sense of the statement in book effective c++. Following is the inheritance diagram for multiple inheritance. Now the book says separate memory in each class is required for vptr. Also it makes following statement An oddity in the above diagram is that there are only three vptrs even though four classes are involved. Implementations are free to generate four vptrs if they like, but three suffice (it turns out that B and D can share a vptr), and most implementations take advantage of this opportunity to reduce the compiler-generated overhead. I could not see any reason why