[boost] Re: [Review] Named parameters library

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-17 21:55:33

"Thorsten Ottosen" <nesotto_at_[hidden]> writes:

> "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. 

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