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.