Conversion constructor vs. conversion operator: precedence
Posted
by GRB
on Stack Overflow
See other posts from Stack Overflow
or by GRB
Published on 2009-09-05T18:47:32Z
Indexed on
2010/04/08
3:33 UTC
Read the original article
Hit count: 723
Reading some questions here on SO about conversion operators and constructors got me thinking about the interaction between them, namely when there is an 'ambiguous' call. Consider the following code:
class A;
class B {
public:
B(){}
B(const A&) //conversion constructor
{
cout << "called B's conversion constructor" << endl;
}
};
class A {
public:
operator B() //conversion operator
{
cout << "called A's conversion operator" << endl;
return B();
}
};
int main()
{
B b = A(); //what should be called here? apparently, A::operator B()
return 0;
}
The above code displays "called A's conversion operator", meaning that the conversion operator is called as opposed to the constructor. If you remove/comment out the operator B()
code from A
, the compiler will happily switch over to using the constructor instead (with no other changes to the code).
My questions are:
- Since the compiler doesn't consider
B b = A();
to be an ambiguous call, there must be some type of precedence at work here. Where exactly is this precedence established? (a reference/quote from the C++ standard would be appreciated) - From an object-oriented philosophical standpoint, is this the way the code should behave? Who knows more about how an
A
object should become aB
object,A
orB
? According to C++, the answer isA
-- is there anything in object-oriented practice that suggests this should be the case? To me personally, it would make sense either way, so I'm interested to know how the choice was made.
Thanks in advance
© Stack Overflow or respective owner