"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uwtwlb7yh.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | | > "David Abrahams" <dave@boost-consulting.com> wrote in message | > news:u4qjqq4is.fsf@boost-consulting.com... | > | Thorsten Ottosen <nesotto@cs.auc.dk> writes: | >
| > | > why can't you store a reference? | > | | > | Because you'd be storing a reference to a temporary, which would have | > | evaporated by the time you get to actually initiate the call. | > | > you must be confusing move-semantics with this situation, or I'm | > missing something. | | You're missing something. | | > there should be no difference between storing a temporary implicitly | > or explicitly...it's still there and still takes up stack-space no | > matter what. | | Yes, but your scheme requires copying that temporary into a new | object, where it is stored again. The proposed library allows a | reference to be bound to the temporary with no copying. And I | seriously doubt there is a compiler in existence today that can elide | that copy, because of the restrictions on where the object must be | stored.
ah, yes I see it now. That is indeed a major benefit.
Where in the standard are those restriction described?
It's described by omission. The standard only gives permission to elide copies and not assignments. Therefore if you construct a subobject and then you assign into it, you have to do the assignment.
I mean I would have suspected that RVO could be extended to support classes like in this:
struct X { Foo f; };
Foo foo();
X x; x.f = foo();
Forget it; it's an assignment.
If I change the interface to set_foo( const Foo& r ) { f = r; } instead of a public member, it is slower, but otherwise not AFAICT (see attachment).
It's still an assignment. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com