🚀 go-pugleaf

In article <4ciauq$2e1@trojan.neta.com> jonnyg@trojan.neta.com (J. Greenblatt) writes:

> 	// This is a non RTTI enabled class, no RTTI overhead, no RTTI keywords
> 	class foo
> 	{
> 	    int i;
> 	};

Actually, that's already more or less the case.  RTTI basically
consists of two parts, dynamic_cast and typeid; in both cases, you
need to distinguish between an expression's static type (its type as
known at compile time) and its dynamic type (the type of an object
pointed to by a pointer or reference).  The two can differ, of course,
since a base class pointer can point to an object of derived class.

If you're simply working with an expression's static type, then there
doesn't need to be any runtime overhead: everything can be done at
compile time.  There's only overhead if you want to find the dynamic
type of an object: that's the only case when you're really doing RTTI
at all.  

The standard distinguishes between polymorphic classes (ones that
declare or inherit virtual functions) and nonpolymorphic classes.  You
can still use dynamic_cast and typeid for nonpolymorphic classes, but
only to work with an expression's static type.  The section on
dynamic_cast says "Otherwise [i.e. for downcasting and conversion from
void*], v shall be a pointer to or an lvalue of a polymorphic type",
and the section on typeid says "If the expression is an lvalue of
polymorphic type (_class.virtual_), the type_info for the complete
object (_class.base.init_) referred to is the result."  

There is already overhead associated with polymorphic classes (the
virtual table); RTTI adds a little bit more, but it shouldn't add any
overhead to nonpolymorphic classes, which are the ones where
presumably one cares about such things.

Polymorphic classes are defined in section 10.3 of the working paper, 
and dynamic_cast and typeid are described in sections 5.2.6 and 5.2.7
respectively.


Matt Austern
SGI: MTI Compilers Group
austern@isolde.mti.sgi.com
-- 
Matt Austern
SGI: MTI Compilers Group
austern@isolde.mti.sgi.com