🚀 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

In article 2e1@trojan.neta.com, jonnyg@trojan.neta.com (J. Greenblatt) writes:

>Problem:

>	It seems that RTTI requires a compile time flag to be activated. When
>activated the code seems to bloat whether you actualy use the feature in the
>specific peice of code or not. From what I have learned this overhead is due
>to extra work done when the object is constructed (A pointer to this with a
>string representation of the class is added to a table).

That sounds like not a very efficient way to implement RTTI. I would
expect all RTTI extensions to consist only of static data, with a pointer
to such static data in the vtable for a type. Vtables are also normally
static data. (Types with no virtual functions don't have RTTI available
anyway, except for built-in types.) The only RTTI overhead is the extra
static data tables, one table per RTTI type. Objects should have no space
or time overhead whatever associated with RTTI. (We are talking about
implementation details here, not language definition. Certainly RTTI
implementations exist that work the way I have described.)

>Proposed solution:

>	Allow RTTI to be implemented on the whole system as it is now and keep
>it as a option. In addition allow RTTI to be turned on on a class by class 
>basis. On a class by class basis RTTI would be enabled if a base of the 
>current class is declared with the RTTI keyword. The extra RTTI keywords 
>(dynamic_cast, static_cast, etc...) are only defined for classes declared 
>as RTTI classes. The RTTI overhead is now only felt when accessing objects
>of RTTI classes.

But every class would have to be declared to be RTTI or they wouldn't
be very useful. A major purpose of classes is to serve as a base for
further development. If you create a FOO class and put it in library,
no client of the class could use RTTI on derived classs unless you
make FOO an RTTI class.

A C++ implementor might choose to have a compiler flag that eliminated
the RTTI data to reduce static data space in programs that don't want
to use RTTI, just as some compilers have a flag that turns off exception
code. That isn't, and IMHO should not be, part of the language definition.
Compilers operating in a no-exception or no-RTTI mode are not truly C++
compilers. The ability to disable such language features is there for those
with severe space constraints.

---
Steve Clamage, stephen.clamage@eng.sun.com



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

In article <4ciauq$2e1@trojan.neta.com> jgreen@amex-trs.com writes:

> 	It seems that RTTI requires a compile time flag to be activated. When
> activated the code seems to bloat whether you actualy use the feature in the
> specific peice of code or not. From what I have learned this overhead is due
> to extra work done when the object is constructed (A pointer to this with a
> string representation of the class is added to a table). This overhead does
> not make RTTI a good addition to C++ but more of a optional addition to those
> who want it (this is how it is implemented now). Also are the addition of key
> words which is not a biggy in this case given the key word names.

There's nothing I can think of in the language that requires
it to be implemented that way.  It is intended to be possible
to implement RTTI by adding an extra field to the virtual function
table, which means there is a small amount of space overhead per
class (not per object) and no time overhead except for the places
in the program where RTTI is actually used.  I can see no reason why
any extra work should have to be done when objects are constructed.
-- 
				--Andrew Koenig
				  ark@research.att.com