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-08 00:09:28
On Thu, Jul 7, 2011 at 8:00 PM, Adam Merz <adammerz_at_[hidden]> wrote:
> My earlier post focused on whether calling `void g(int const volatile&)`
> with an
> int rvalue would be legal (it isn't), but that was partially misplaced --
> relevant part of the standard is overload resolution.
> Starting from the top, quoting the C++03 standard, §184.108.40.206/3:
> > A well-formed implicit conversion sequence is one of the following forms:
> > - a standard conversion sequence,
> > - a user-defined conversion sequence, or
> > - an ellipsis conversion sequence.
> > When comparing the basic forms of implicit conversion sequences
> > - a standard conversion sequence is a better conversion sequence than a
> user-defined conversion sequence or an ellipsis conversion sequence,
> > - a user-defined conversion sequence is a better conversion sequence
> than an
> ellipsis conversion sequence.
> §220.127.116.11.4 repeats multiple times that for the case where the parameter
> type is
> a reference, that a standard conversion is taking place; however I won't
> all that here.
> So with the overloads:
> void g(int const volatile&);
> void g(...);
> When calling g with an int rvalue, the compiler must select the
> `void g(int const volatile&)` overload because "a standard conversion
> is a better conversion sequence than a user-defined conversion sequence or
> ellipsis conversion sequence". Only then does the compiler decide that
> `void g(int const volatile&)` with an int rvalue is illegal. And this is
> without precendence -- quoting §18.104.22.168.4/4:
> > Other restrictions on binding a reference to a particular argument do not
> > affect the formation of a standard conversion sequence, however.
> [Example: a
> > function with a "reference to int" parameter can be a viablecandidate
> even if
> > the corresponding argument is an int bit-field. The formation of implicit
> > conversion sequences treats the int bit-field as an int lvalue and finds
> > exact match with the parameter. If the function is selected by overload
> > resolution, the call will nonetheless be ill-formed because of the
> > on binding a non-const reference to a bit-field.]
> Summary: Intel *is correct* according to the standarde, but GCC and MSVC
> the sane/practical route.
What is a "standard conversion sequence"?
[ I don't have a copy of the standard; if it's freely available on the
internet somewhere, freely point me in the right direction :) ]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk