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]) ...
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk