Re: [boost] [type traits extension] test for const volatile& as return type

Subject: Re: [boost] [type traits extension] test for const volatile& as return type
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-07-05 22:38:27

On Tue, Jul 5, 2011 at 7:19 PM, Edward Diener <eldiener_at_[hidden]>wrote:

> On 7/5/2011 3:50 PM, Frédéric Bron wrote:
>
[...]

> This is what I get with g++ 4.6.0 for different values of T:
>> - int&: g(...)
>> - const int&: g(T)
>> - volatile int&: g(...)
>> - const volatile int&: g(...)
>>
>> This is what I get with intel 11.1:
>> - int&: g(...)
>> - const int&: g(T)
>> - volatile int&: g(...)
>> - const volatile int&: error: initial value of reference to const
>> volatile must be an lvalue
>>
>> g++ is just fine for what I want to do but intel issues an error if T
>> is "const volatile&" so that the program cannot compile and the g(...)
>> is not chosen. Does anybody understands if this is the right behaviour
>> according to the standard or if g++ is right chosing g(...)?
>>
>
>
> I think you need to reproduce your exact case. Your code above can not tell
> anyone what is actually going on.
>

I'm not sure that's entirely fair; it just may not have been presented in
the clearest way.  The crux of the matter is, unless I'm missing something,
that GCC prefers binding an rvalue of type int to f(...) rather than f(const
volatile int&), while Intel just barfs when offered those alternatives.  My
limited understanding of overload resolution and function argument binding
says that GCC is right, and there should be no error, but I have no
authoritative sources to back that up, so don't take my word for it.

On the bright side, at least Intel doesn't ICE like MSVC does on some even
relatively mild TMP :)

- Jeff