[Gdal-dev] RE: need RTTI for OGR (Windows)

[Mateusz Łoskot]

Frank Warmerdam wrote:
> Mateusz Łoskot wrote:
> 
>> Chapman, Martin wrote:
>> 
>>> [...] You will just have to use a C style cast like:
>> 
>> 
>> It's better to use C++ static_cast<>() operator than C style.
>> 
>>> OGRGeometry *poGeometry ....  // not null ... switch 
>>> (poGeometry->getGeometryType()) { ..... case wkbPolygon: MyFunc(
>>>  (OGRPolygon*)poGeometry);
>> 
>> 
>> MyFunc( static_cast<OGRPolygon*>(poGeometry) );
>> 
>> Here static_cast<>() will work well because it's used to cast down 
>> the hierarchy what's very common/.
>> 
>> NOTE: when if poGeometry points not to OGRPolygon base class, then 
>> it will cause run-time error. So, it's not safer than dynamic_cast 
>> but safer than C style. NOTE 2: static_cast<>() is very native and 
>> does not decrease performance in any way.
>> 
>> NOTE 3 about NOTE 2: Generally, casting is pretty expansive 
>> operation, so there is always some overhead :-)
> 
> 
> Mateusz,
> 
> I don't know why you way that casting is generally an expensive 
> operation. A C cast is "free".  It does not involve any runtime work.
>  It just tells the compiler some information type information for use
>  at compile time.

AFAIK, not every casting is only a compile time case.
When you're dealing with polymorphic structures compiler
does not (may not) know exact types behind the pointer or reference
playing in particular case.

Second, as I've learned from different game programming gurus (e.g. Gems
books series) casting cost is about >=80 CPU cycles.
So, if program operates on e.g. 1000000 point objects through pointer to
the base class e.g. Shape then casting cost is quite significant,
isn't it?
Simply, I've learned it as one of opposite argument
against using virtual polymorphism in games
programming and other performance critical software.

Cheers
-- 
Mateusz Łoskot
http://mateusz.loskot.net