[boost] Re: [Review] Named parameters library

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-11-17 19:39:51

"David Abrahams" <dave_at_[hidden]> wrote in message
news:usm786nvn.fsf_at_boost-consulting.com...
| "Thorsten Ottosen" <nesotto_at_[hidden]> 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