"David Abrahams" <dave@boost-consulting.com> wrote in message news:usm786nvn.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | > ah, yes I see it now. That is indeed a major benefit. | > until we have move-semantics, that is :-) | > 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. Hm...I ran the code...it's as fast as passing the object directly to the function. Are the compilers doing anything they shouldn't ??? Here's my take on it: a compiler is allowed to a remove any copy operations as long as the programs observed behavior is the same. AFAICT, copying (or assigning) a vector<int> (compared to not doing it) will never change the observed behavior. -Thorsten