🚀 go-pugleaf

In article <MATT.95Sep7112147@physics10.Berkeley.EDU>,
fjh@munta.cs.mu.OZ.AU (Fergus Henderson) wrote:

>> Or were you proposing to define semantics for `dynamic_cast<bar>(foo)'
>> in the case where `bar' is type `type_info'?  (In that case, shouldn't
>> you have said dynamic_cast<const type_info&>?  Why require the
>> type_info to be a modifiable lvalue?)  If you were proposing to define
>> semantics for `dynamic_cast<bar>(foo)', what would be the static type
>> of that expression?  What would be the behaviour at run-time?

Fergus,

I know my article wasn't that clear, so I'll explain again :

Yes, what I ment was 'dynamic_cast<bar>(foo)' where 'bar' is a 'const
type_info&'.

First, the usage :

A 'const type_info&' is stored somewhere, and I want to use this data to
try and cast a pointer ( or a reference ) to the type that is represented
by the stored type_info.

The implementation :

I've seen two compilers that implemented dynamic_cast. In both, the
expression 'dynamic_cast<T*>(p)' was translated to a function call ( a
runtime library function, of course ), and the parameters were the RTTI
object, and some other stuff for p, including the RTTI object of the
static type of p. 'RTTI object' is something that can actually be the
known type_info& object returned from typeid.

A simple implementation of 'typeid' will be to have a pointer in the
virtual table to point to an 'extended' type_info structure, meaning that
the type_info structure that we know from 'typeinfo.h' has actually more
fields. That's why you can't copy it or derive from it ( it has only one
constructor, the copy-constructor, which is private, and the operator= is
also private ).

So, the conclusion from this SHORT study-case, is that the STATIC type in
the expression 'dynamic_cast<T*>(p)' is NOT a static type at all.

From here, it's easy to understand that the STATIC RETURN TYPE of the
exspression 'dynamic_cast<T*>(p)' should be T*, as it is now.

So, what I'm actually saying is that if it's possible to perform the
dynamic_cast without knowing the T being used, why not do so ?

My suggestion is that if the compiler encounters an expression like :

'dynamic_cast<ATypeInfo>(p)' were ATypeInfo is a 'const type_info&'

the compiler won't try to cast p to ATypeInfo, which will ALWAYS fail, but
it will try to cast p to the type ATypeInfo contains data for.

Have Fun,
Etay.

-- Etay Bogner,
-- Etay_Bogner@mail.stil.scitex.com,
-- Scitex Corp.
-- Israel.

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]