From: David Abrahams (dave_at_[hidden])
Date: 2004-02-08 15:07:05
Brian McNamara <lorgon_at_[hidden]> writes:
> On Sun, Feb 08, 2004 at 11:39:51AM -0500, David Abrahams wrote:
>> Brian McNamara <lorgon_at_[hidden]> writes:
>> > David Abrahams writes:
>> >> 12.2/1 says that the act of binding an rvalue to a (const) reference
>> >> creates a temporary (which may be elided). The creation of the
>> >> temporary requires the existence of a copy ctor with a const&
>> >> argument. As far as I know, that rule serves no useful purpose, but I
>> >> may have missed something.
>> > I am not sure what portion of the rule you don't like. Is it the fact
>> > that they point to a particular copy constructor (the const& one),
>> > rather than just any available/visible/something copy constructor?
>> No, it's the fact that any additional temporary at all (and thus, a
>> copy ctor) is needed.
>> > In test10, what do you 'want' to happen here:
>> > sink2( <a temporary object, that is, an rvalue> );
>> It should bind a const reference to the temporary without complaining
>> that the temporary can't be copied.
> I see. What about
> const X& x = source(); // 12.2/5
> ? Or something.
That's exactly the case I'm talking about.
> I am trying to find the 'hard' cases where the
> compiler might not be able to easily make the temporary have the right
> 'lifetime', and thus require an extra copy.
I don't see any problem here. There's no problem getting the rvalue
out of source(), or sink(source()) would fail. Furthermore, no
compiler I've ever seen will actually make the allowed temporary in
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk