On Sep 27, 2004, at 9:09 AM, Thorsten Ottosen wrote:
From: "Howard Hinnant" <hinnant@twcny.rr.com>
| On Sep 27, 2004, at 2:46 AM, Thorsten Ottosen wrote: | | > "Howard Hinnant" <hinnant@twcny.rr.com> 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