If I have one base class and I derive 10 different concrete derived classes from it then will each and every concrete derived class have a different vtable?
A:
Depends on whether your derived classes override/declare any virtual methods.
EFraim
2009-08-02 12:02:37
+4
A:
If the base class or all of the derived classes have any virtual functions, then yes, usually. Why is it important?
Two classes can only share a vtable if they have an indentical set of virtual functions. So a derived class can only share a vtable with a base class if it doesn't override any virtual functions.
A derived class can't share a vtable with any other derived class unless they both don't override any functions of the same base class as - even if implemented in the same way - the member functions of one derived class are a different type from the member functions of a different derived class.
Charles Bailey
2009-08-02 12:03:26
i was just confused that whether all the derived classes gonna use a single v table or they gonna have different
2009-08-02 12:04:29
yes indeed every derived class is over riding the virtual functions of their own since the base class is purely abstract so are there gonna b seprate v tables???
2009-08-02 12:05:45
They can only share a vtable if they have an indentical set of virtual functions. This means that a derived class can only share a vtable with a base class if it doesn't override any virtual functions.
Charles Bailey
2009-08-02 12:05:48
thanks alot....................
2009-08-02 12:08:52
Two classes can never share the vtable. This table contains not only pointers to virtual members, but also the information needed by RTTI.
AProgrammer
2009-08-02 12:34:32
Note all C++ compilers agressively optimise vtables often by using thunks etc so I'd never 100% rely on a vtable being there as you'd expect
zebrabox
2009-08-02 12:46:07
@AProgrammer: Usually true, yes. There's no requirment that RTTI has to be implemented as part of the vptr/vtbl mechanism, though. Of course, there's no language requirement to use vtables at all but it is the most common implementation strategy.
Charles Bailey
2009-08-02 12:53:16
@zebrabox: I'm not sure how thunks in vtables would be an optimization, but yes, in general, compilers can do any 'magic' they like with vtables.
Charles Bailey
2009-08-02 12:55:14
@Charles Bailey. Here's a PDF that explains thunk optimisation http://www.cs.ucsb.edu/~urs/oocsb/papers/oopsla96.pdf. Though I will say that the optimisation is only really effective for multiple inheritance. Also 'thunk' in this context is bad term is it's more a wrapper function but the name thunk seems to have stuck
zebrabox
2009-08-02 13:44:19
Theoretical question: Is there anything in the C++ specs that forces implementing virtual functions via vtables? I think it is the best method to implement them but in theory there could be C++ implementations that resolve virtual functions addresses in a very different way.
rstevens
2009-08-02 16:12:45
@rstevens: Not at all. By far the most trivial counterexample is inlining the vtable itself in every object, instead of inserting a vtable pointer. Saves you one level of indirection but is almost certain to increase object size.
MSalters
2009-08-03 08:39:30