In article <1151700409.770743.258080@h44g2000cwa.googlegroups .com>,
"mlimber" <mlimber@gmail.com> wrote:
[color=blue]
> Howard Hinnant wrote:[color=green]
> > "mlimber" <mlimber@gmail.com> wrote:[color=darkred]
> > > Right, and some have sole ownership semantics like std::tr1::scoped_ptr
> > > (aka boost::scoped_ptr) which do not have problems with circular
> > > references.[/color]
> >
> > There is no std::tr1::scoped_ptr. There is only boost::scoped_ptr.[/color]
>
> I hadn't noticed that! Any idea why was it not included, too?
> (According to
http://boost.org/libs/smart_ptr/smart_ptr.htm#History,
> the semantics of scoped_ptr were the original semantics for auto_ptr,
> but the recommendation of Library Working Group was ignored and
> transfer-of-ownership semantics were added to auto_ptr. I find the ToO
> semantics quite useful at times, but at the same time adding scoped_ptr
> in C++0x would seem to provide a smart pointer that is not susceptible
> to accidental destructive copying and would thus serve as the usual
> RAII resource manager. In that scheme, auto_ptr would be relegated only
> to transferring ownership and would be rather inaptly named.)[/color]
I can give only my personal opinion, and not anything official.
I am seeking to deprecate auto_ptr and replace it with unique_ptr:
http://www.open-std.org/jtc1/sc22/wg...56.html#20.4.5
%20-%20Class%20template%20auto_ptr
The link above describes the motivation for deprecating auto_ptr. It
also introduces and completely describes unique_ptr as the safer
replacement. unique_ptr also offers ownership transfer like auto_ptr,
but not with copy syntax as auto_ptr does. Instead it uses move syntax
(which is easily searched for in source code). Given this, accidental
ownership transfer is no longer something to worry about. unique_ptr
functionality is a superset of boost::scoped_ptr, and not likely to be
accidently abused (as is auto_ptr). Thus I'm personally lacking
motivation to have a scoped_ptr in addition to unique_ptr.
Fwiw, here:
http://home.twcny.rr.com/hinnant/cpp...nique_ptr.html
are some minor improvements to the unique_ptr interface which have
surfaced since the publication of N1856 and which I hope to standardize
as well.
If you have use cases for scoped_ptr that unique_ptr is unsuitable to
fulfill, I would be most interested in hearing about them (so that
scoped_ptr could also be proposed for standardization, or so that
unique_ptr could be improved to meet those use cases). Or if you would
just like to question how unique_ptr would behave in certain contexts
(compared to scoped_ptr or auto_ptr), please feel free to ask me
(publicly or privately).
-Howard