Re: [boost] Re: Reference documentation

From: David Abrahams (dave_at_[hidden])
Date: 2002-11-01 19:01:13

"Kevin S. Van Horn" <Kevin.VanHorn_at_[hidden]> writes:

> to which David Abrahams responded:
> 
> > I think you're confused. The copy is owned by the virtual machine,
> > since it gets created on the stack. Usually, "take ownership of" only
> > applies to heap objects whose lifetimes can be managed by their
> > owners.
> 
> Not necessarily: consider use of swap and move constructors

I'm fully aware of move constructors, believe me.

>  (or, more properly, Andrei's MOJO techique for approximately
> implementing move constructors).  Both of these allow us to "take
> ownership of" a temporary, or at least its internals.  (OK, strictly
> speaking, this is not what is usually meant by "take ownership"; I
> guess I should have chosen my terminology more carefully.)

Yes.

> This all goes back to the discussion Andrei started a couple of
> weeks ago about move constructors and MOJO.  For example, consider
> the canonical strongly exception safe assignment operator:
> 
>   X& operator=(X const & x) {
>     X tmp(x);
>     tmp.swap(*this);
>     return *this;
>   }

...which should not be canonical...

> As Andrei pointed out, if a temporary gets bound to x, then we have
> two copies.  An alternative is
> 
>   X& operator=(X x) {
>     x.swap(*this);
>     return *this;
>   }
> 
> which involves fewer copies is a temporary gets bound to x, and the same
> number of copies as the first implementation for "x1 = x" if x is an lvalue.
> 
> The point of all this is that I, as an implementor, should have the
> freedom to fiddle with such implementation details without changing
> the specification of the class, and I cannot do this if the
> signature of the operation is fixed in the specification instead of
> using valid expressions to specify the operation.

I'm not prepared to rewrite all of Boost's documentation in terms of
valid expressions, are you?

And, BTW, techniques like Mojo are not transparent. They /do/ affect
interface in subtle ways.

-- 
                    David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com