Why is this not ambiguous?

[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?
}

[Ali Çehreli]

REH wrote:

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

[REH]

"Ali Çehreli" <ac******@yahoo .com> wrote in message
news:3b******** *****@individua l.net...

REH wrote:

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

[Ioannis Vranos]

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

[Ioannis Vranos]

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

[REH]

"Ioannis Vranos" <iv*@remove.thi s.grad.com> wrote in message
news:1112248707 .384234@athnrd0 2...

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

[Ioannis Vranos]

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

[Marcelo Pinto]

"Howard" <al*****@hotmai l.com> wrote in message news:<s_******* ************@bg tnsc04-news.ops.worldn et.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.