Hello, c++ gurus.

The Jan 96 WP says (section 4.10, Pointer conversions)

------------------------------------------------------------------------
3 An rvalue of type "pointer to cv D," where D is a class type,  can  be
  converted  to  an  rvalue of type "pointer to cv B," where B is a base
  class (class.derived) of D. If B is an inaccessible
  (class.access) or ambiguous (class.member.lookup) base class of D,
  a program that necessitates this conversion is ill-formed.

------------------------------------------------------------------------

Is it implies, that there is standard conversion from pointer
to derived class to a pointer to ambigous base class. It is significant
for overloading.

Example:
------------------------------------
class A {
};

struct B1: public A {};
struct B2: public A {};

struct B: B1, B2 {};

void f (void *)
{
 printf ("f(void*)\n");
}

void f (A *)
{
 printf ("f(A*)\n");
}

main ()
{
 B b;
 f (&b);
}
------------------------------------

In this example GNU G++ selects the f(void *), this mens that g++ do
not consider conversion of B* to A* as standard conversion, but
according to last WP, is shall, and this example should be
illegal. Is it possible to change wording of the rule in 4.10 ?

Thank you.
--
Alexander N. Krotoff
Research Computer Center
Moscow State University
---
[ 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                             ]

Alexander Krotoff <krotoff@such.srcc.msu.su> writes:

>The Jan 96 WP says (section 4.10, Pointer conversions)
>
>3 An rvalue of type "pointer to cv D," where D is a class type,  can  be
>  converted  to  an  rvalue of type "pointer to cv B," where B is a base
>  class (class.derived) of D. If B is an inaccessible
>  (class.access) or ambiguous (class.member.lookup) base class of D,
>  a program that necessitates this conversion is ill-formed.
>
>Is it implies, that there is standard conversion from pointer
>to derived class to a pointer to ambigous base class. It is significant
>for overloading.
>
>Example:
[condensed by fjh:]
>
>class A {};
>struct B1: public A {};
>struct B2: public A {};
>struct B: B1, B2 {};
>void f (void *) { ... }
>void f (A *) { ... }
>main () { B b; f (&b); }
>
>In this example GNU G++ selects the f(void *), this mens that g++ do
>not consider conversion of B* to A* as standard conversion, but
>according to last WP, is shall, and this example should be
>illegal.

If g++ behaves as you describe, then that's a bug in GNU C++.

>Is it possible to change wording of the rule in 4.10 ?

It would be possible to do so, but I don't think it would be a good
idea.  Examples like the one you posted *should* be ambiguous, IMHO.  I
think it would be very confusing and error-prone if `f(void *)' were
selected even though `f(A*)' was a better match.  If you really want
the compiler to select a particular way of handling the ambiguity,
you can always do it explicitly by define a function `f(D *)' as
either
 void f(D* d) { f((void *)d); }
or
 void f(D* d) { f((B1*)d); }
or
 void f(D* d) { f((B2*)d); }

But I think it would be very dangerous for the compiler to pick
any one of these three different ways of resolving the ambiguity;
whichever one was chosen, there would be a high chance it was
the wrong one.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.


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