On Thu, Jul 7, 2011 at 4:27 PM, Adam Merz <adammerz@hotmail.com> wrote:
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.
By this logic, void f(int&); void f(...) f(i++) should also fail to compile, no? I would think that the failure of an int rvalue to initialize either an int& or an int const volatile & would simply drop that overload from consideration. - Jeff