🚀 go-pugleaf

In trying to trace a perceived bug in g++2.7.2 to the DWP, I
found that it seems vague.  I have paraphrased to save space.  If
I messed it up, say so.  In the following, assume B is a polymorphic
base of D and that A is unrelated.

5.2.6 Dynamic cast [expr.dynamic.cast]

/1 dynamic_cast<T>(v)  T shall be a pointer or reference to a complete
class type, or pointer to cv void.

-- clear

/2 v shall be a pointer or reference to a complete class type.  T and
v must both be pointers or both be references.

-- clear
dynamic_cast<A*>(0) is an error since int is not a pointer to complete
class type.
dynamic_cast<A*>(NULL) is an error since NULL ((void*)0) is not a pointer
to complete class type.
g++ flags them.

/3 "If the type of v is the same as the required result type (which,
for convenience, will be called R ..., the result is v ..."

-- clear
dynamic_cast<A*>(reinterpret_cast<A*>(0)) is ok and g++ accepts it.
This is basically a noop.

/4 "If the value of v is a null pointer value in the pointer case, the
result is the null pointer of type R."

-- not quite clear
g++ interpreted the use of R here to mean that only case /3 null pointers
were converted via a noop.  The remaining cases require non null pointers.
It crashes on null pointers.

/5 If the T is to a base class of the v, the result is the unique base
sub-object of the v.

-- hum
The offset can be calculated at compile time and no run time check is
needed.  What happens to null?

/6 Otherwise, v shall be to a polymorphic type.

-- hum
shall be a pointer to, which could be null?

/7 If T is pointer to cv void, result is to complete object of v.
Otherwise, run time check.

-- clear
Compile time offset again.  Null?

/8 Runtime: If v is to public base of a T, result is to that T
   else if the complete v has a base T, the result is that T
   else fails

-- hum
Nothing has said that T and v must be related.  It seems that
dynamic_cast<A*>(someD*) is a valid statement which always fails.

/9 failed pointer is null, reference throws.

-- clear
Example contains two C-style casts.  Should they be new style?

Food for thought,
John


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]