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: Adam Merz (adammerz_at_[hidden])
Date: 2011-07-07 19:27:03

Frédéric Bron <frederic.bron <at> m4x.org> writes:
> <snip>
> 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(...)?

By my reading, the Intel compiler is correct in refusing to compile. Quoting
§8.5.3/5 from the C++03 standard:

> A reference to type "cv1 T1" is initialized by an expression of type "cv2 T2"
> as follows:
>   - If the initializer expression
>     - [1] is an lvalue (but is not a bit-field), and "cv1 T1" is reference-
>       compatible with "cv2 T2," or
>     - [2] has a class type (i.e., T2 is a class type) and can be implicitly
>       converted to an lvalue of type "cv3 T3," where "cv1 T1" is reference-
>       compatible with "cv3 T3" (this conversion is selected by enumerating the
>       applicable conversion functions and choosing the best one through
>       overload resolution),
>     then <snip...>
>   - [3] Otherwise, the reference shall be to a non-volatile const type (i.e.,
>     cv1 shall be const).

If I interpret this correctly,
- [1] is not applicable because you're passing an rvalue
- [2] is not applicable because int is not a class type
- [3] specifically disallows volatile

Obviously the wording in the C++0x FDIS differs, but still ultimately disallows
this particular scenario.

That said, I'm inclined to say that GCC and MSVC are in the wrong here, not
Intel.