linux-kernel - Re: Kernel Development & Objective-C

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 01 Dec 2007 21:55:59 +0200
From:	Avi Kivity <avi@...o.co.il>
To:	Al Viro <viro@....linux.org.uk>
CC:	"J.A. Magall??n" <jamagallon@....com>,
	Lo??c Greni?? <loic.grenie@...il.com>,
	Ben.Crowhurst@...llatravel.co.uk, linux-kernel@...r.kernel.org
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.

--
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/