[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071201003119.GB8181@ftp.linux.org.uk>
Date: Sat, 1 Dec 2007 00:31:19 +0000
From: Al Viro <viro@....linux.org.uk>
To: "J.A. Magall??n" <jamagallon@....com>
Cc: Lo??c Greni?? <loic.grenie@...il.com>,
Ben.Crowhurst@...llatravel.co.uk, linux-kernel@...r.kernel.org
Subject: Re: Kernel Development & Objective-C
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists