Boost logo

Boost :

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
that case.

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at