Re: Compiler chooses conv ctor - why?
Alex Blekhman wrote:
"Cezary H. Noweta" wrote;
It seems that according to 13.3 of ISO 14882 none of the
sequences is better then other. Thus ambiguity should occur
causing error.
It seems like a compiler bug. I tried the folowing code and it
fails to compile with Comeau C++ as expected:
-------
struct B;
struct A {
operator B() const;
};
struct B {
B() {}
B(const A&) {}
};
A::operator B() const
{ return *((B*)0); }
void foo(B) {}
int main()
{
A a;
B b = a; // Bug! Should not compile.
foo(a); // OK. Fails to compile.
return 0;
}
-------
OK - thank you. I've tested above example with various compilers, which
produced several different effects:
MSC12.0, MSC14.0: #1: conversion constructor called; #2: error (like in
your comments)
Watcom 1.7.1: #1, #2: conversion function called
Intel 7.1, Gnu 3.4.4: #1, #2: conversion constructor called
Certainly, it seems to be a bug. Hopefully I'm not blind ;)
Removing of const qualifier from A::operator B() will drop away an
ambiguity, as according to 13.3.3.2[3], a qualification conversion of an
implicit object parameter (B& to const B&) makes the constructor worse
conversion sequence and the conversion function should be chosen. Is
this right? If so, then there is another (or the same) bug in MSC, which
chooses a conversion constructor in such case.
-- best regards
Cezary Noweta