"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"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.
Fine, show me your test and I'll show you what's wrong with it.
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.
You're kidding, right? I doubt very much that the compiler can legitimately decide that side effects on the memory subsystem due to allocation are not observable. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com