Re: Kernel Development & Objective-C
From: Avi Kivity
Date: Sat Dec 01 2007 - 14:58:38 EST
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/