Dennis Schridde schreef:
> Am Dienstag, 6. März 2007 schrieb Dennis Schridde:
>   
>> Am Dienstag, 6. März 2007 schrieb Giel van Schijndel:
>>     
>>> Author: muggenhor
>>> Date: Tue Mar  6 22:21:13 2007
>>> New Revision: 854
>>>
>>> URL: http://svn.gna.org/viewcvs/warzone?rev=854&view=rev
>>> Log:
>>>  * Add Vertex base class (bases/vertex.hpp) to derive from for an
>>> interface to a coordinate set (x,y,z-coords from listener and sound
>>> source) * class soundDecoding:
>>>   * Add soundDecoding::getSampleCount() which retrieves the amount of
>>> samples contained in the opened audio file (only works when file is
>>> seekable) * Remove dual decoding function in favor of the one that
>>> allocates a buffer on its own * interface.cpp:
>>>   * Modify templated function validID() to also modify the ID number with
>>> a constant correction (ID -= 1) * Fix sound_Destroy2DStream to check the
>>> ID number for validity before using it * add subclass soundListener to
>>> soundContext which is derived from Vertex, this is to handle the listener
>>> seperately * class soundSource:
>>>   * Removed initialization of OpenAL Source with a bunch of zeros
>>>   * fix some error strings
>>>   * Derive from Vertex and implement all its interface (virtual)
>>> functions
>>>       
>> Maybe we are getting philosophical here, but is a soundListener or a
>> soundSource a Vertex? Shouldn't it _contain_ a Vertex?
>>     
> PS: I just saw the "virtual" in that sentence... As of what I know and have 
> heard "virtual" and "vmt" is a synonym for death when used in a game...
> Afaik this makes it utterly slow and is not a very good choice for a basic 
> base class like this...
>   
Erm, virtual a synonym for death?

Well lets start with basics then.
When using a virtual function the compiler will generate a vtable
(virtual function table) for all base classes and derived classes. This
is implemented as an array of function pointers. The increase of code
size caused by this will however be negligible (IMO those 20 byte don't
really matter). Additionally the memory footprint of each instantiated
class will increase by the size of a pointer (pointer to the vtable).
This is IMO also negligible.

So that only performance left.
The only occasion when performance can be affected by virtual functions
is when they're called.

Here it is important to know that (according to the naive compiler
implementation model) calling a virtual function is roughly equivalent
to calling a function through a pointer stored in an array.

Call to virtual function:
px->f(an_argument);

Equivalent pointer-to-function version:
object->vtable[functionnum](object, an_argument);

So what happens is this. Firstly the pointer to the vtable is retrieved
(directly contained in the object, so won't be anything fancy), then an
offset into that table is used to retrieve the function address. Then
lastly the function is called with (a pointer to) the object to operate
on as additional argument (this is with all classes/structs, virtual or
not).

Now RTTI (RunTime Type Information) on the other hand that can kill
performance. That basically traverses your entire inheritance hierarchy.
But then again I don't use RTTI. Only in C++ exception handling I
_implicitly_ use that (i.e. exception handling requires RTTI), but even
then only when an exception is thrown RTTI is used to determine the
correct exception handler.

So my conclusion: using virtual functions has a constant (i.e. O(1) )
increase in memory usage (i.e. sizeof(pointer*)), and has a constant
O(2) increase in time used/operations performed (i.e. two additional
pointer dereferences, the first to the vtable the second to the function)

Oh btw I happen to program C++ for embedded systems so I _had_ to learn
all ^ that stuff (I had/have fun with it though).

-- 
Giel

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Reply via email to