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

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

[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

           Summary: typecast vs. constructor ambiguity
           Product: gcc
           Version: 3.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hovik at melikyan dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-portbld-freebsd5.1
  GCC host triplet: i386-portbld-freebsd5.1
GCC target triplet: i386-portbld-freebsd5.1

	

G++ 3.3 gives an error message when there is an ambiguity between an explicit typecast operator
and a constructor, whereas all previous versions of g++ and also BCC and MSVC use the typecast
operator in this situation.

The appended code causes the following error:

gccbug.cxx: In function `int main()':
gccbug.cxx:27: error: call of overloaded `ClassOne(ClassTwo&)' is ambiguous
gccbug.cxx:3: error: candidates are: ClassOne::ClassOne(const ClassOne&)
gccbug.cxx:7: error:                 ClassOne::ClassOne(int)
gccbug.cxx:27: warning: unused variable `ClassTwo b'
*** Error code 1


Interestingly, there is no such constructor `ClassOne(ClassTwo&)' in the code, while gcc
calls it 'ambigious' in the message above.

Environment:
System: FreeBSD miles.netflute.com 5.1-RELEASE FreeBSD 5.1-RELEASE #0: Thu Jun 5 02:55:42 GMT 2003 root@wv1u.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC i386


host: i386-portbld-freebsd5.1
build: i386-portbld-freebsd5.1
target: i386-portbld-freebsd5.1
configured with: ./..//gcc-3.3/configure --disable-nls --with-gxx-include-dir=/usr/local/lib/gcc-lib/i386-portbld-freebsd5.1/3.3/include/c++/3.3 --with-system-zlib --disable-shared --prefix=/usr/local i386-portbld-freebsd5.1

How-To-Repeat:


class ClassOne
{
public:
    int data;

    ClassOne(int i)                      { data = i; }
};
        

class ClassTwo
{
public:
    int data;

    ClassTwo()                           { data = 0; }
    ClassTwo(const ClassOne& o)          { data = o.data; }

    operator int()                       { return data; }
    operator ClassOne()                  { return ClassOne(data); }
};


int main()
{
    ClassTwo a;
    ClassTwo b = ClassOne(a);
    return 0;
}

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

[pinskia at physics dot uc dot edu]

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


pinskia at physics dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |rejects-valid
   Last reconfirmed|0000-00-00 00:00:00         |2003-08-01 18:31:12
               date|                            |


------- Additional Comments From pinskia at physics dot uc dot edu  2003-08-01 18:31 -------
I can confirm this is rejected in the mainline (20030801).
ICC 6.0 in strict mode accepted this.

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

[reichelt 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 reichelt at gcc dot gnu dot org  2003-08-04 23:55 -------
I'm not sure if this is really a bug.
The error message actually makes sense to me:

gccbug.cxx:27: error: call of overloaded `ClassOne(ClassTwo&)' is ambiguous

In line 27 we actually have "ClassOne(a)", where "a" is of type "ClassTwo".
And there are really two ways to construct "ClassOne" from "ClassTwo":

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).
Unfortunately, I don't know the correct answer.

(Btw, Intel 7.1 also rejects the code with a similar error message.)

Finally, here's a shorter testcase:
---------------------------------------------------------
struct X
{
    X(int) {}
};

struct Y
{
    operator int() { return 0; }
    operator X()   { return X(0); }
};

Y y;
X x(y);
---------------------------------------------------------

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

[pinskia at physics dot uc dot edu]

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 pinskia at physics dot uc dot edu  2003-08-05 00:05 -------
ICC 6.0 calls "ClassTwo::operator ClassOne()" then "ClassTwo::ClassTwo(ClassOne const&)" but I 
think this is invalid now looking at the code some more but I am not the last person who has that 
say.

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

[hovik at melikyan dot com]

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.

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

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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
   Last reconfirmed|2003-08-01 18:31:12         |2003-08-23 15:28:46
               date|                            |

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

[dhazeghi at yahoo dot com]

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


dhazeghi at yahoo dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|i386-portbld-freebsd5.1     |
   GCC host triplet|i386-portbld-freebsd5.1     |
 GCC target triplet|i386-portbld-freebsd5.1     |
   Last reconfirmed|2003-08-23 15:28:46         |2003-08-24 17:18:58
               date|                            |


------- Additional Comments From dhazeghi at yahoo dot com  2003-08-24 17:18 -------
Mainline (20030817) still gives:

foo.cc:13: error: call of overloaded `X(Y&)' is ambiguous
foo.cc:2: note: candidates are: X::X(const X&)
foo.cc:3: note:                 X::X(int)

Has it been determined whether the code is valid or not?

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2003-12-28 22:09 -------
No the conversion is ambiguous.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


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