Hi guys,

I have taken the example from the standard C++ document section 5.2.7
(dynamic_cast explanation) point 9. This is the example (one aspect of
it that I am interested in)

class A { virtual f(); };
class B { virtual g(); };
class D : public virtual A, private B {};

void g() {
 D d;
 B* bp = (B*) &d; // cast needed to break protection

-----> D& dr = dynamic_cast <D&> (*bp); // fails
}

The statement pointed to always succeed in gnu compilers (version
2.95.2), who is at fault here? is it a compiler bug?

thanks for you help.

regards
georges

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> I have taken the example from the standard C++ document section 5.2.7
> (dynamic_cast explanation) point 9. This is the example (one aspect of
> it that I am interested in)
>
> class A { virtual f(); };
> class B { virtual g(); };
> class D : public virtual A, private B {};
>
> void g() {
> D d;
> B* bp = (B*) &d; // cast needed to break protection
>
> -----> D& dr = dynamic_cast <D&> (*bp); // fails
> }
>
> The statement pointed to always succeed in gnu compilers (version
> 2.95.2), who is at fault here? is it a compiler bug?


The standard states (somewhere) that a C-style cast is the only way to break
protection (eg private base class subobjects). If gnu 2.95.2 finds such a
private base class subobject dynamically, it is non-conforming in that
respective.

TiTi


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Georges Samara <georges@redjupiter.demon.co.uk> wrote:

> Hi guys,
>
> I have taken the example from the standard C++ document section 5.2.7
> (dynamic_cast explanation) point 9. This is the example (one aspect of
> it that I am interested in)
>
> class A { virtual f(); };
> class B { virtual g(); };
> class D : public virtual A, private B {};
>
> void g() {
>   D d;
>   B* bp = (B*) &d; // cast needed to break protection
>
> ----->    D& dr = dynamic_cast <D&> (*bp); // fails
> }
>
> The statement pointed to always succeed in gnu compilers (version
> 2.95.2), who is at fault here? is it a compiler bug?

    There's nothing wrong with the compiler failing to cast to it's
private base class. That's the whole point of making the base class
private (i.e. it hides the is-a relationship).


--
http://www.whereismyhead.com/clark/
Clark S. Cox, III
clarkcox3@yahoo.com

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hi,

Thanks guy for clearing this up. The compiler should have failed as stated
in the document, but it is not and so it is faulty.

Thanks


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Jason Merrill (jason@cygnus.com) wrote:
: >>>>> John E Potter <jpotter@falcon.lhup.edu> writes:

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

: I think the WP is pretty clear that a null pointer should not be adjusted
: or dereferenced.  I have fixed this in g++ for 2.8.

That was also my first impression; however, the more I read it the less
clear it became.  The two options were: (1) Make a run time test for
null pointer in all cases like delete.  (2) Let the user beware of null
pointers like all other cases.  Not sure what the committee intended.

Did you also change it to allow dynamic_cast<Some*>(0)?  I thought that
that g++ error was correct after several reads.

What about the dynamic_cast<Unrelated*>(SomePolymorphic*)?  Is that a
compile time error or a run time test which always fails?

Thanks,
John
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

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                             ]

>>>>> John E Potter <jpotter@falcon.lhup.edu> writes:

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

I think the WP is pretty clear that a null pointer should not be adjusted
or dereferenced.  I have fixed this in g++ for 2.8.

Jason


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