[Bug c++/11765] typecast vs. constructor ambiguity
hovik at melikyan dot com
gcc-bugzilla@gcc.gnu.org
Tue Aug 5 08:00:00 GMT 2003
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.
More information about the Gcc-bugs
mailing list