I'm having a hard time understanding the example in section 5.4 paragraph
5 of the standard:

   struct A {};
   struct I1 : A {};
   struct I2 : A {};
   struct D : I1, I2 {};

   A *foo (D *p) { return (A*) (p); }  // ill-formed static_cast interpretation

What, exactly, is an "ill-formed static_cast interpretation"?  My read
of section 5.2.9 is that casting to an ambiguous base cannot be
interpreted as a static_cast at all (it is not covered by any of the
conversions listed in that section) and that the correct behavior of
this example, according to 5.4, is to fall through to the
reinterpret_cast interpretation, rather than for the whole cast
expression to be "ill-formed".

-Sandra

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <m3pums11wv.fsf@lilypad.concmp.com>,
  Sandra Loosemore <sandra@shore.net> wrote:
> I'm having a hard time understanding the example in section 5.4
paragraph
> 5 of the standard:
>
>    struct A {};
>    struct I1 : A {};
>    struct I2 : A {};
>    struct D : I1, I2 {};
>
>    A *foo (D *p) { return (A*) (p); }  // ill-formed static_cast
interpretation
>
> What, exactly, is an "ill-formed static_cast interpretation"?  My read
> of section 5.2.9 is that casting to an ambiguous base cannot be
> interpreted as a static_cast at all (it is not covered by any of the
> conversions listed in that section) and that the correct behavior of
> this example, according to 5.4, is to fall through to the
> reinterpret_cast interpretation, rather than for the whole cast
> expression to be "ill-formed".

5.4 appears to have been written based on the understanding
that a derived-to-base pointer cast is a standard conversion
and that static_cast is intended to handle standard
conversions.  However, as you point out, the description in
5.2.9 doesn't say that static_cast handles standard
conversions; instead, it relies on the "invented temporary"
circumlocution to cover standard conversions, constructor
conversions, and conversion functions in one fell swoop.
This descriptive shortcut does not support the assumption
that was made in the 5.4 example, since the ambiguity
causes the initialization of the invented temporary to be
ill-formed and thus disqualifies the static_cast
interpretation of the old-style cast.

This strikes me as sufficiently problematic that I will
include it as an issue in the next revision of the Core
Language issues list, unless someone points out something
I've overlooked that harmonizes these two approaches.
Thanks for pointing out the problem.

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

wmm@fastdial.net writes:

> 5.4 appears to have been written based on the understanding
> that a derived-to-base pointer cast is a standard conversion
> and that static_cast is intended to handle standard
> conversions.  However, as you point out, the description in
> 5.2.9 doesn't say that static_cast handles standard
> conversions; instead, it relies on the "invented temporary"
> circumlocution to cover standard conversions, constructor
> conversions, and conversion functions in one fell swoop.
> This descriptive shortcut does not support the assumption
> that was made in the 5.4 example, since the ambiguity
> causes the initialization of the invented temporary to be
> ill-formed and thus disqualifies the static_cast
> interpretation of the old-style cast.
>
> This strikes me as sufficiently problematic that I will
> include it as an issue in the next revision of the Core
> Language issues list, unless someone points out something
> I've overlooked that harmonizes these two approaches.
> Thanks for pointing out the problem.

While you're at it, a couple other situations that might fit into
the same category are casting "pointer to member of C" to
"pointer to member of B" where B is a virtual base of C, and
casting a "pointer to B" to "pointer to C", again where B is
a virtual base of C.  These are not valid static_cast operations,
but again it's not clear whether they're "ill-formed" or not.

-Sandra

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]