Subject: Re: [boost] [type traits extension] test for const volatile& as return type
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-07-07 20:50:30
On Thu, Jul 7, 2011 at 4:27 PM, Adam Merz <adammerz_at_[hidden]> 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.
> §8.5.3/5 from the C++03 standard:
> > A reference to type "cv1 T1" is initialized by an expression of type "cv2
> > as follows:
> > - If the initializer expression
> > -  is an lvalue (but is not a bit-field), and "cv1 T1" is
> > compatible with "cv2 T2," or
> > -  has a class type (i.e., T2 is a class type) and can be
> > converted to an lvalue of type "cv3 T3," where "cv1 T1" is
> > compatible with "cv3 T3" (this conversion is selected by
> enumerating the
> > applicable conversion functions and choosing the best one through
> > overload resolution),
> > then <snip...>
> > -  Otherwise, the reference shall be to a non-volatile const type
> > cv1 shall be const).
> If I interpret this correctly,
> -  is not applicable because you're passing an rvalue
> -  is not applicable because int is not a class type
> -  specifically disallows volatile
> Obviously the wording in the C++0x FDIS differs, but still ultimately
> this particular scenario.
> That said, I'm inclined to say that GCC and MSVC are in the wrong here, not
By this logic,
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk