Messages in this thread | | | Date | Sat, 01 Dec 2007 21:55:59 +0200 | From | Avi Kivity <> | Subject | Re: Kernel Development & Objective-C |
| |
Al Viro wrote: > On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote: > >> An vtable in C++ takes exactly the same space that the function >> table pointer present in every driver nowadays... and probably >> the virtual method call that C++ does itself with >> >> thing->do_something(with,this) >> >> like >> push thing >> push with >> push this >> call THING_vtable+indexof(do_something) // constants at compile time >> > > This is not what vtables are. Think for a minute - all codepaths arriving > to that point in your code will pick the address to call from the same > location. Either the contents of that location is constant (in which case > you could bloody well call it directly in the first place) *or* it has to > somehow be reassigned back and forth, according to the value of this. The > former is dumb, the latter - outright insane. > > The contents of vtables is constant. The whole point of that thing is > to deal with the situations where we _can't_ tell which derived class > this ->do_something() is from; if we could tell which vtable it is at > compile time, we wouldn't need to bother at all. > > It's a tradeoff - we pay the extra memory access (fetch vtable pointer, then > fetch method from vtable) for not having to store a slew of method pointers > in each instance of base class. But the extra memory access is very much > there. It can be further optimized away if you have several method calls > for the same object next to each other (then vtable can be picked once), > but it's still done at runtime. >
True. C++ vtables have no performance advantage over C ->ops->function() calls. But they have no disadvantage either and they do offer many syntactic advantages (such as automatically casting the object type to the *correct* derived class.
| |