🚀 go-pugleaf

"Etay Bogner" <Etay_Bogner@mail.stil.scitex.com> writes:

>[...] why not have a dynamic_cast<type_info&) ?
>
>So one can pass a type_info, which was NOT obtained via typeid(), to a
>function which will, among others, use dynamic_cast ...

I don't understand your suggestion.  I suspect that it is a half-baked
idea which when analyzed will turn out to not make any sense.  But if
you are willing to explain it, I'm willing to explore it further.

The syntax `dynamic_cast<type_info&>(foo)' already has a defined
meaning.  Were you proposing to change this?  If so, what semantics
do you propose, and how do they differ from the existing semantics?

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 Henderson             |  #define x t=a[i],a[i]=a[m],a[m]=t
                             |  char a[]=" 12345678";main(m,i,j,t){for(i=m;i<
fjh@cs.mu.oz.au              |  9;x,i++)for(x,j=m;--j?(t=a[m-j]-a[m])-j&&t+j:
http://www.cs.mu.oz.au/~fjh  |  main(m+1)*0;);m-9||puts(a+1);} /* 8 queens */

---
[ 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. ]

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. ]

Etay Bogner <Etay_Bogner@mail.stil.scitex.com> writes:

>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) wrote:
>
>>> 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?
[...]
>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.
[...]
>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.

I already know that the static type of `dynamic_cast<T*>(p)' is `T*',
because `dynamic_cast<T*>(p)' is already part of standard C++.
What I am asking about is the static type of your newly proposed syntax
`dynamic_cast<bar>(foo)', where `bar' is a value of type type_info, not
a type.

I think your idea doesn't make sense, because there *isn't* any sensible
static type for that expression.  Since C++ is a statically typed language,
every expression must have a static type, but that expression can't have
one.  Therefore it doesn't work in C++.

>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 ?

Because in fact it is not possible, unless the result of the dynamic_cast
is discarded.  The reason the compiler needs to know the type is
so that it can statically typecheck the containing expression.

>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.

And supposing the compiler encounters an expression like

	int f(const type_info& ATypeInfo) {
		int x = dynamic_cast<ATypeInfo>(p);
		return x;
	}

what is the compiler going to do then?  Type-check the initialization
of `x' at run-time?  I suppose that would be do-able, but it wouldn't
be easy, and it certainly wouldn't be C++.

-- 
Fergus Henderson             |  #define x t=a[i],a[i]=a[m],a[m]=t
                             |  char a[]=" 12345678";main(m,i,j,t){for(i=m;i<
fjh@cs.mu.oz.au              |  9;x,i++)for(x,j=m;--j?(t=a[m-j]-a[m])-j&&t+j:
http://www.cs.mu.oz.au/~fjh  |  main(m+1)*0;);m-9||puts(a+1);} /* 8 queens */

---
[ 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. ]

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

>> I already know that the static type of `dynamic_cast<T*>(p)' is `T*',
>> because `dynamic_cast<T*>(p)' is already part of standard C++.
>> What I am asking about is the static type of your newly proposed syntax
>> `dynamic_cast<bar>(foo)', where `bar' is a value of type type_info, not
>> a type.
>> 
>> I think your idea doesn't make sense, because there *isn't* any sensible
>> static type for that expression.  Since C++ is a statically typed language,
>> every expression must have a static type, but that expression can't have
>> one.  Therefore it doesn't work in C++.

The sensible static type for that expression will be a 'void*'.

I know this sounds ugly, but so does 'dynamic_cast<void*>(p)', which as
I'm sure you know, returns a pointer to the complete object, but in the
form of a void*.

The issue here is that one has the ability to 'cast-down' to the complete
object, using 'dynamic_cast<void*>(p)' ( meaning, without knowing the
complete type type) and getting a void*, but no ability to 'cast-up' ( an
implicit procedure in C++ ) without knowing the sub-type type at compile
time.

This is needed in the same cases it is needed when using the returned
pointer from 'dynamic_cast<void*>(p)', to do the inverse-operation.

Please look at another article of mine in this thread for a usage and an
implementation.

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. ]

(A copy of this message has also been posted to the following newsgroups:
comp.std.c++)

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

>> I already know that the static type of `dynamic_cast<T*>(p)' is `T*',
>> because `dynamic_cast<T*>(p)' is already part of standard C++.
>> What I am asking about is the static type of your newly proposed syntax
>> `dynamic_cast<bar>(foo)', where `bar' is a value of type type_info, not
>> a type.
>> 
>> I think your idea doesn't make sense, because there *isn't* any sensible
>> static type for that expression.  Since C++ is a statically typed language,
>> every expression must have a static type, but that expression can't have
>> one.  Therefore it doesn't work in C++.

The sensible static type for that expression will be a 'void*'.

I know this sounds ugly, but so does 'dynamic_cast<void*>(p)', which as
I'm sure you know, returns a pointer to the complete object, but in the
form of a void*.

The issue here is that one has the ability to 'cast-down' to the complete
object, using 'dynamic_cast<void*>(p)' ( meaning, without knowing the
complete type type) and getting a void*, but no ability to 'cast-up' ( an
implicit procedure in C++ ) without knowing the sub-type type at compile
time.

This is needed in the same cases it is needed when using the returned
pointer from 'dynamic_cast<void*>(p)', to do the inverse-operation.

Please look at another article of mine in this thread for a usage and an
implementation.

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. ]

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

>> I already know that the static type of `dynamic_cast<T*>(p)' is `T*',
>> because `dynamic_cast<T*>(p)' is already part of standard C++.
>> What I am asking about is the static type of your newly proposed syntax
>> `dynamic_cast<bar>(foo)', where `bar' is a value of type type_info, not
>> a type.
>> 
>> I think your idea doesn't make sense, because there *isn't* any sensible
>> static type for that expression.  Since C++ is a statically typed language,
>> every expression must have a static type, but that expression can't have
>> one.  Therefore it doesn't work in C++.

The sensible static type for that expression will be a 'void*'.

I know this sounds ugly, but so does 'dynamic_cast<void*>(p)', which as
I'm sure you know, returns a pointer to the complete object, but in the
form of a void*.

The issue here is that one has the ability to 'cast-down' to the complete
object, using 'dynamic_cast<void*>(p)' ( meaning, without knowing the
complete type type) and getting a void*, but no ability to 'cast-up' ( an
implicit procedure in C++ ) without knowing the sub-type type at compile
time.

This is needed in the same cases it is needed when using the returned
pointer from 'dynamic_cast<void*>(p)', to do the inverse-operation.

Please look at another article of mine in this thread for a usage and an
implementation.

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. ]