«

Can some tell me why the chooses the constructor in class B over operator B
in class A? Is this not ambiguous?

Thanks.


#include <iostream>

using namespace std;

struct A;

struct B {
B() {}
B(const A&) {} // this is choosen
};

struct A {
A() {}
operator B() const {return B();} // this is not
};

int main()
{
A a;
B b;

b = a; // ambiguous?
}

REH wrote:
> Can some tell me why the chooses the constructor in class B over operator B
> in class A? Is this not ambiguous?

I am not sure I understand the first question. The program is ill-formed
because the "b = a" _is_ in fact ambiguous.

>
> Thanks.
>
>
> #include <iostream>
>
> using namespace std;
>
> struct A;
>
> struct B {
> B() {}
> B(const A&) {} // this is choosen
> };
>
> struct A {
> A() {}
> operator B() const {return B();} // this is not
> };
>
> int main()
> {
> A a;
> B b;
>
> b = a; // ambiguous?
> }


V

"REH" <> wrote in message
news:d2ejdb$...
> Can some tell me why the chooses the constructor in class B over operator
> B
> in class A? Is this not ambiguous?
>
> Thanks.
>
>
> #include <iostream>
>
> using namespace std;
>
> struct A;
>
> struct B {
> B() {}
> B(const A&) {} // this is choosen
> };
>
> struct A {
> A() {}
> operator B() const {return B();} // this is not
> };
>
> int main()
> {
> A a;
> B b;
>
> b = a; // ambiguous?
> }
>

I think the answer is given in Stroustrup's "The C++ Programming Language",
p277: "User-defined conversions are considered only if they are neccessary
to resolve a call." I don't have the Standard to back up that statement,
but if he's correct, then the fact that a copy-constructor exists that can
handle the job negates the need to bother looking at other alternatives.
Thus, no ambiguity is encountered.

-Howard

* REH:
> Can some tell me why the chooses the constructor in class B over operator B
> in class A? Is this not ambiguous?
>
> Thanks.
>
>
> #include <iostream>
>
> using namespace std;
>
> struct A;
>
> struct B {
> B() {}
> B(const A&) {} // this is choosen
> };
>
> struct A {
> A() {}
> operator B() const {return B();} // this is not
> };
>
> int main()
> {
> A a;
> B b;
>
> b = a; // ambiguous?
> }

Comeau online compilation:

Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing. All rights reserved.
MODE:strict errors C++

"ComeauTest.c", line 18: error: more than one user-defined conversion from "A"
to
"const B" applies:
function "A:perator B() const"
function "B::B(const A &)"
b = a; // ambiguous?
^

1 error detected in the compilation of "ComeauTest.c".

In strict mode, with -tused, Compile failed

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

As far as the microsoft VS.NET 2003 compiler is concerned this is an
error.

Grant

"Alf P. Steinbach" <> wrote in message
news:...
> * REH:
> > Can some tell me why the chooses the constructor in class B over
operator B
> > in class A? Is this not ambiguous?
> >
> > Thanks.
> >
> >
> > #include <iostream>
> >
> > using namespace std;
> >
> > struct A;
> >
> > struct B {
> > B() {}
> > B(const A&) {} // this is choosen
> > };
> >
> > struct A {
> > A() {}
> > operator B() const {return B();} // this is not
> > };
> >
> > int main()
> > {
> > A a;
> > B b;
> >
> > b = a; // ambiguous?
> > }
>
> Comeau online compilation:
>
> Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
> Copyright 1988-2003 Comeau Computing. All rights reserved.
> MODE:strict errors C++
>
> "ComeauTest.c", line 18: error: more than one user-defined conversion from
"A"
> to
> "const B" applies:
> function "A:perator B() const"
> function "B::B(const A &)"
> b = a; // ambiguous?
> ^
>
> 1 error detected in the compilation of "ComeauTest.c".
>
> In strict mode, with -tused, Compile failed
>
That's interesting. Even compiling with all warnings, GCC failed to
complain. I would file a bug report, but I'm not sure which is correct. I
just trying it with VC 2003 ToolKit, and says:

error C2679: binary '=' : no operator found which takes a right-hand operand
of type 'A' (or there is no acceptable conversion)

Which I think is wrong, or at least misleading. I guess I will have to look
in the standard, which is hard for me to comprehend.

"Victor Bazarov" <> wrote in message
news:qOA2e.58433$ o.verio.net...
> REH wrote:
> > Can some tell me why the chooses the constructor in class B over
operator B
> > in class A? Is this not ambiguous?
>
> I am not sure I understand the first question. The program is ill-formed
> because the "b = a" _is_ in fact ambiguous.
>
Sorry, that first question should have read, "Can some tell me why then
compiler chooses the constructor in class B over operator B in class A?"
Meaning, instead of complaining about the ambiguity, my compiler, given the
choice of:

1) B::B(const A&);
2) A:perator B() const;

It chose option #1.

REH wrote:
> "Alf P. Steinbach" <> wrote in message
>> "ComeauTest.c", line 18: error: more than one user-defined
>> conversion from "A" to
>> "const B" applies:
>> function "A:perator B() const"
>> function "B::B(const A &)"
>> b = a; // ambiguous?

> That's interesting. Even compiling with all warnings, GCC failed to
> complain.

Get a newer gcc; version 3.4.2 spots the ambiguity.

Ali

"Ali Çehreli" <> wrote in message
news:...
> REH wrote:
> > "Alf P. Steinbach" <> wrote in message
> >> "ComeauTest.c", line 18: error: more than one user-defined
> >> conversion from "A" to
> >> "const B" applies:
> >> function "A:perator B() const"
> >> function "B::B(const A &)"
> >> b = a; // ambiguous?
>
> > That's interesting. Even compiling with all warnings, GCC failed to
> > complain.
>
> Get a newer gcc; version 3.4.2 spots the ambiguity.
>
> Ali
>

Um, I *am* using 3.4.2. What is your targetted for?

"REH" <> wrote in message
news:d2evpm$...
>
> "Ali Çehreli" <> wrote in message
> news:...
> > Get a newer gcc; version 3.4.2 spots the ambiguity.
> >
> > Ali
> >
>
> Um, I *am* using 3.4.2. What is your targetted for?
>
>
I just tried it with version 3.4.3, and it still accepts it.