Boost logo

Boost :

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>> 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

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