Boost logo

Boost :

From: Eric Niebler (eric_at_[hidden])
Date: 2005-12-19 14:28:40

Thorsten Ottosen wrote:
> Eric Niebler wrote:
>>I noticed this too, and decided it was a bug in gcc. I think that given
>> template<typename T> struct conv {
>> operator T() { return T(); }
>> };
>> template<typename T> void bar(T&) {}
>>the expression:
>> typedef foo const cfoo;
>> bar(true ? conv<foo>() : cfoo());
>>should compile,
> Even though bar takes a T& and not const T& parameter?

Yes. The type of (true ? conv<foo>() : cfoo()) is "rvalue of foo const."
And const rvalues successfully bind to T&, with T deduced as "foo const."

> It seems to me that conversion operators are a poorly understood part of
> the language. Maybe you should take this up on the reflector.

Just because you and I don't understand this completely doesn't mean
it's poorly understood by everyone. :-)

> Another thing I find wierd is that this seems to lead to ambiguity:
> template< class T >
> struct probe
> {
> operator T&();
> operator T();
> };
> int main()
> {
> int i = probe<int>(); // error
> int& r = probe<int>(); // ok
> }
> If I add const to the T() conversion, it suddenly works ok again.

Yes, that's because for the first line, there are two ways for the
conversion to succeed. It could call operator T(), or it could call
operator T&() followed by the standard lvalue-to-rvalue conversion.
Overload resolution is needed to choose between them, and without the
const qualification, neither is preferred. With the const, an extra
standard non-const-to-const conversion is needed before operator
T&()const can be invoked, which makes that conversion sequence longer
and less preferred.


Eric Niebler
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at