By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,261 Members | 1,325 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,261 IT Pros & Developers. It's quick & easy.

Why is this not ambiguous?

P: n/a
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?
}

Jul 23 '05 #1
Share this Question
Share on Google+
16 Replies


P: n/a
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
Jul 23 '05 #2

P: n/a

"REH" <bo***@nowhere.net> wrote in message
news:d2*********@cui1.lmms.lmco.com...
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

Jul 23 '05 #3

P: n/a
* 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::operator 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?
Jul 23 '05 #4

P: n/a
As far as the microsoft VS.NET 2003 compiler is concerned this is an
error.

Grant

Jul 23 '05 #5

P: n/a
REH

"Alf P. Steinbach" <al***@start.no> wrote in message
news:42****************@news.individual.net...
* 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::operator 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.

Jul 23 '05 #6

P: n/a
REH

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:qO*******************@newsread1.mlpsca01.us.t 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::operator B() const;

It chose option #1.

Jul 23 '05 #7

P: n/a
REH wrote:
"Alf P. Steinbach" <al***@start.no> wrote in message
"ComeauTest.c", line 18: error: more than one user-defined
conversion from "A" to
"const B" applies:
function "A::operator 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

Jul 23 '05 #8

P: n/a
REH

"Ali «ehreli" <ac******@yahoo.com> wrote in message
news:3b*************@individual.net...
REH wrote:
"Alf P. Steinbach" <al***@start.no> wrote in message
"ComeauTest.c", line 18: error: more than one user-defined
conversion from "A" to
"const B" applies:
function "A::operator 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?

Jul 23 '05 #9

P: n/a
REH

"REH" <bo***@nowhere.net> wrote in message
news:d2*********@cui1.lmms.lmco.com...

"Ali «ehreli" <ac******@yahoo.com> wrote in message
news:3b*************@individual.net...
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.

Jul 23 '05 #10

P: n/a
REH wrote:
"Ali ehreli" <ac******@yahoo.com> wrote in message
news:3b*************@individual.net...
Get a newer gcc; version 3.4.2 spots the ambiguity.

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


It turns out, the compiler option that catches this is

-pedantic

Ali

Jul 23 '05 #11

P: n/a
REH

"Ali «ehreli" <ac******@yahoo.com> wrote in message
news:3b*************@individual.net...
REH wrote:
"Ali ehreli" <ac******@yahoo.com> wrote in message
news:3b*************@individual.net...

Get a newer gcc; version 3.4.2 spots the ambiguity.

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


It turns out, the compiler option that catches this is

-pedantic

Ali


Thanks. I assumed that "-ansi" would catch it, but it does not.

Jul 23 '05 #12

P: n/a
REH wrote:
That's interesting. Even compiling with all warnings, GCC failed to
complain.

C:\c>g++ -std=c++98 -pedantic-errors -Wall temp.cpp -o temp.exe
temp.cpp: In function `int main()':
temp.cpp:22: error: conversion from `A' to `const B' is ambiguous
temp.cpp:14: note: candidates are: A::operator B() const
temp.cpp:9: note: B::B(const A&)

C:\c>


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #13

P: n/a
REH wrote:
Thanks. I assumed that "-ansi" would catch it, but it does not.


The complete g++ options that I am using may help:
-std=c++98 -pedantic-errors -Wall -O3 -ffloat-store -mtune=pentium3

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #14

P: n/a
REH

"Ioannis Vranos" <iv*@remove.this.grad.com> wrote in message
news:1112248707.384234@athnrd02...
REH wrote:
Thanks. I assumed that "-ansi" would catch it, but it does not.


The complete g++ options that I am using may help:
-std=c++98 -pedantic-errors -Wall -O3 -ffloat-store -mtune=pentium3

--
Ioannis Vranos

http://www23.brinkster.com/noicys


Thanks. As another poster informed me, it was "-pedantic" that does the
trick. Though, I don't understand why you have to utilize an option to get
GCC to report this as an error.

REH
Jul 23 '05 #15

P: n/a
REH wrote:
Thanks. As another poster informed me, it was "-pedantic" that does the
trick. Though, I don't understand why you have to utilize an option to get
GCC to report this as an error.

GCC considers itself smarter than this, I guess. :-) Or in other words, it considers that
the copy (=conversion) constructor of the type on the left that is assigned the value of
the type on the right, makes sense to be used (or in other words, it considers that type
conversions (copy constructors) have more priority than compatibility operators).

Theoretically speaking, both should have the same end result. But I think no one would
define both of them on purpose, so here we are. :-)

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #16

P: n/a
"Howard" <al*****@hotmail.com> wrote in message news:<s_*******************@bgtnsc04-news.ops.worldnet.att.net>...

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


The Standard says, in 12.3-2:
User-defined conversions are applied only where they are unambiguous
(10.2, 12.3.2).

Thus, I believe it's an error to provide the two conversions, because
they are always ambigous and thus could not be applied.

On the other hand, The Standard says, in 12.3.2-1:
"... Classes, enumerations, and typedef-names shall not be declared in
the typespecifier-seq. ..."

So I believe that the conversion operator to B is invalid.

I may be interpreting The Standard wrongly, though.

Regards,

Marcelo Pinto.
Jul 23 '05 #17

This discussion thread is closed

Replies have been disabled for this discussion.