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.