[Bug c++/11765] typecast vs. constructor ambiguity

["hovik at melikyan dot com" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11765



------- Additional Comments From hovik at melikyan dot com  2003-08-05 08:00 -------
>
> 1) Apply "ClassTwo::operator ClassOne()"
> 2) Apply "ClassTwo::operator int()" and then "ClassOne::ClassOne(int)".
>
> The question is: Should 1) be preferred over 2)?
> You say "yes", gcc says "no" (since gcc 2.95.x).
>

Actually, gcc starting from 3.3, not 2.95.

This comes from a real-world example. I have a string class and also a variant 
class in my library. Variant is automatically castable to many other types 
(like ClassTwo in the sample code), including the string, while string 
(ClassOne) doesn't know anything about the variant class. Prior to gcc 3.3 you 
could explicitly cast string(v), where v is a variant object, but starting from 
3.3 the compiler rejects this code. Many other compilers accept such typecasts 
as well, though I didn't try Intel's cc.

And besides, as far as I can understand, this message "call of overloaded 
`ClassOne(ClassTwo&)' is ambiguous" doesn't make any sense because there is no 
such contructor ClassOne(ClassTwo&), neither it can be automatically generated.