Precedence of overloaded cast operators

[Ross]

I have a problem regarding the precedence of overloaded cast operators.
My program is as follows:

#include <stdio.h>

class A;

class B {
public:
B(A &a) {
printf("construct\n");
}
};

class A {
public:
B f() {
printf("f\n");
return(B(*this));
}

operator B () {
printf("convert\n");
return(f());
}
};

int main() {
A a;
a.f();
return(0);
}

When I compile and run the program on Linux using g++, the output is:

f
construct

This is pretty much what I'd expect. However, when I do the same on a
HP-UX system using aCC, the output is:

f
convert
f
convert
f
convert
f
convert
....

This continues until the stack overflows. It seems that the overloaded
cast operator has higher precedence than the contructor of B. I
appreciate this isn't the place to ask about specific C++ compilers, so
my question is: am I making unreasonable assumptions about what the
correct behaviour of C++ should be in these situations?

Thanks in advance,
Ross

 

[Victor Bazarov]

I have a problem regarding the precedence of overloaded cast
operators. My program is as follows:

#include <stdio.h>

class A;

class B {
public:
B(A &a) {
printf("construct\n");
}
};

class A {
public:
B f() {
printf("f\n");
return(B(*this));
}

operator B () {
printf("convert\n");
return(f());
}
};

int main() {
A a;
a.f();
return(0);
}

When I compile and run the program on Linux using g++, the output is:

f
construct

This is pretty much what I'd expect. However, when I do the same on a
HP-UX system using aCC, the output is:

f
convert
f
convert
f
convert
f
convert
...

This continues until the stack overflows. It seems that the overloaded
cast operator has higher precedence than the contructor of B. I
appreciate this isn't the place to ask about specific C++ compilers,
so my question is: am I making unreasonable assumptions about what the
correct behaviour of C++ should be in these situations?

5.2.3 requires that the expression B(*this) is interpreted as a c-tor
invocation (construction of a value of type B). So, I think HP's aCC
is wrong.

V

 

[Frederick Gotham]

Victor Bazarov:

5.2.3 requires that the expression B(*this) is interpreted as a c-tor
invocation (construction of a value of type B). So, I think HP's aCC
is wrong.

Are you saying the following?

When the following syntax is encountered:

A(obj_b)

, the compiler shall search for a constructor for A before it searches for
a conversion operator for B?

The following compiles OK for me with g++:

class A {};

class B {
public:

operator A() const
{
return A();
}
};

int main()
{
A obj_a;
B obj_b;

obj_a = obj_b;

obj_a = A(obj_b);
}

Even though the "function call syntax" or whatever you want to call it is
used, the conversion operator is still invoked. But are you saying that a
constructor must be sought before a conversion operator is sought?

 

[Victor Bazarov]

Victor Bazarov:



Are you saying the following?

When the following syntax is encountered:

A(obj_b)

, the compiler shall search for a constructor for A before it
searches for a conversion operator for B?

The following compiles OK for me with g++:

class A {};

class B {
public:

operator A() const
{
return A();
}
};

int main()
{
A obj_a;
B obj_b;

obj_a = obj_b;

obj_a = A(obj_b);
}

Even though the "function call syntax" or whatever you want to call
it is used, the conversion operator is still invoked. But are you
saying that a constructor must be sought before a conversion operator
is sought?

Yes. However, in this case A(const A&) is the constructor invoked,
and the reference is the one bound to a temporary returned from the
conversion operator ('B:perator A()'). Try adding a parameterised
constructor to A and making it private.

class A { A(class B const&); public: A(); }; // I changed this

class B {
public:
operator A() const { return A(); }
};

int main()
{
A obj_a;
B obj_b;

obj_a = obj_b; // now it's ambiguous
obj_a = A(obj_b); // now it cannot access the c-tor
}

AFAICT, in the original variation both cases _can_ be made equivalent
by the compiler because it is allowed to eliminate extra temporaries.

V