[boost] Re: [review] Formal review of the Smart Container librarystarts today

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-09-27 09:58:30

On Sep 27, 2004, at 9:09 AM, Thorsten Ottosen wrote:

> From: "Howard Hinnant" <hinnant_at_[hidden]>
>
>
> | On Sep 27, 2004, at 2:46 AM, Thorsten Ottosen wrote:
> |
> | > "Howard Hinnant" <hinnant_at_[hidden]> wrote in message
>
> | > | But elements can be moved into or out of the container:
> | > |
> | > | sole_ptr<T> t = move(v[i]);
> | > | v.push_back(move(t));
> | >
> | > so move(v[i]) must also erase the element and then move
> | > the rest of the vector one place back?
> |
> | Nope. move(v[i]) would move from the sole_ptr<T> at i, but not erase
> | it.  v[i] would now own nothing.  This is another difference between
> | this future language I'm describing, and the Smart Container Library.
> | The former allows null pointers where the latter doesn't.
>
> hm...I don't get this...what happens then if I try to access v[i]? Do 
> I get
> undefined behavior?

It depends on what you do with v[i].  You could (for example):

if (v[i]) ...
or
v[i].reset(new T);
or
v[i] = call_func_returning_sole_ptr();

and all of that is well defined.

But if you try to dereference a sole_ptr<T> which owns no object, then 
you fall into undefined behavior:

*v[i] = t;  // run time error, null dereferenced

In a nutshell, you can view container<sole_ptr<T>> just like 
container<auto_ptr<T>>, except the former is safe from accidental 
moving because it won't move (from lvalues) with copy syntax like 
auto_ptr does.  But it will move (from lvalues) with syntax that 
doesn't look like copy.  Also container<sole_ptr<T>> will actually 
compile (someday) which is a really nice bonus (compared to 
container<auto_ptr<T>>)! ;-)

-Howard