Re: ambiguous overload in 2.8.1 and 2.91.60

[Nathan Sidwell <nathan at acm dot org>]

Here is a simplified version of your code,

struct A {
A(int d);
};

struct B {
operator A() const;
operator int() const;
};

A fn(B const &s)
{
  A v(s);
  return v;
}

There are two constructors for A, A::A(int) and A::A(A const &), the latter is
implicitly defined by the compiler. The consruction of v in fn, has to use one
of these constructors. The first requires a convertions from B to int, and one
is provided B::operator int(), the second requires a conversion from B to A,
and one is provided B::operator A(). As both of these are user conververions,
both constructors are equally viable candidates. Earlier compilers might not
have implicitly defined the copy ctor, if there were any explicit ctors. This
appears to have changed.

> Of course, here I could reorder the classes and specify a constructor
> myfloat(const str16 &) instead of the operator myfloat(). But if the
> first class cannot be changed (for instance, in a given header file)
> this workaround is impossible.
Yup, and IMHO is one reason why `explicit' should be applicable to conversion
operator functions as well as constructors.

> Is this a new feature or a bug? And what should I do?
write
 A v((int)s); // don't write A v(int(s));
to force the first path. or
 A v(s.operator A());
to force the second.

nathan
-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
      You can up the bandwidth, but you can't up the speed of light      
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk