Who uses RTTI for games? You''d be surprised...

Actually at runtime, correct implementation of virtual function call requires a check at cast time. Look it up in Aho, not the dragon book, but the other one.

What''s Aho?

Well, you''re going to have to show me some reason that that would be true, because I can''t see any possible situation it would occur in.

x = sprite->DoSomething();

is exactly the same as

x = ((Sprite *)voidPtr)->DoSomething();

When you cast something, the compiler treats it as if it were really a pointer of the given type. It gets compiled as a Sprite *, not a casted void *.

Rock

There is an interesting article on casting at the following address.

Click Here

With respect to C++ it explains casting and all of the problems and benefits of it. Even with static_cast there are memory operations that have to occur. The performance hit for casting comes in making the memory transformations associated with casts. Compiler mileage may vary but here is what I believe happens in the following statement.

int a = 3, b = 4;
float c;
c = (float) a/b;
Both a and b are converted to float.
The division occurs.
The assignment occurs.

float a=3.0, b=4.0;
float c;
The division occurs.
The assignment occurs.

Of course this is simple but even here you can see that there are less steps to the latter example meaning less processor time.

Kressilac
ps Consider more complex classes as discussed in the article above and you begin to see that casting can and does have performance issues even if they end up not being the biggest performance problem in your program. (ie Casting between classes where constructors have to be called each time)


Edited by - kressilac on 1/24/00 3:47:14 PM

If we''re discussing C++ and casting, you should
note that doing C style casting is not a recommended
habit.

C++ casting has these options:
static_cast() compile time check
const_cast() compile time check
dynamic_cast() run time check
reinterpret_cast() no check

The last one is the closest to C style casting
and should be avoided unless necessary.

Using c style casting may reduce type safety.


Photon

Aho is Alfred V. Aho. He''s most famous for _Compilers: Principles, Techniques and Tools_ along with Sethi and Ullman, also known as the "dragon book".

quote:
x = sprite->DoSomething();
is exactly the same as
x = ((Sprite *)voidPtr)->DoSomething();

Actually it''s not. A proper C++ implementation will make sure that the voidPtr isn''t a descended class from Sprite that either is a private descendent or has other symantic weirdness. Even if RTTI is disabled, a proper C++ cast will need to check this. Note this is an action only within the cast. A similar check at the time of the cast happens for polymorphic classes.

Without RTTI, the program has no way of checking
the object type at run time.

even at compile time, with such a cast, the compiler
will not put too much effort into checking this,
since this type of casting overrides all type
checks in pointers.

Ahhh, is that what you guys mean when you say C++ casts? I didn''t even know those existed. I stand corrected in that context. Sorry, and thanks for the link.

As for C style casts, which is what I use and will continue to use, I stand by my claim that it has no performance penalty for the cast (float to int or BYTE to WORD or others like that obviously do, but pointer casts don''t). Yes it is not type safe, but I think that any time casting is done the developer should really take a look and see if it is neccessary. Often times that is a symptom of a poor design from my experience. A handful of casts are easy to make type safe.

For my example above, the cast and no-cast lines DO perform the exact same assembly instructions. There is no penalty. If you miscast, the program crashes. Its a trade-off, which is representative of the trade-offs between C and C++ in general. C is faster, but can be more error prone.

Rock

The "performance hit" of which SiCrane speaks is that which is incurred by using a virtual function instead of a non-virtual function. A class which has virtual functions contains a hidden virtual function table (vtable) which stores pointers to each virtual function. If a derived class overrides any of the virtual functions, the vtable entries for that object will point to the derived-class functions instead of the base-class functions. This is regardless of whether it is referenced by a base- or derived-class pointer.

So in your normal function call you just need one instruction to fetch the function pointer, you need a couple (two? three?) instructions because you have a double-pointer (pointer to a function pointer) to fetch. In the grand scheme of things, it''s really not much of a performance hit to use polymorphism

Rock2000: yes, most people are used to C style casting
and feel uncomfortable with moving to this new syntax.
however, using static_cast can help you avoid alot of
mistakes that take longer to find using a debugger.

Stoffel: All your points are absolutely correct, but it
has nothing to do with the casting issue that was argued.