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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev