Re: auto_ptr vs. boost shared_ptr
Howard Hinnant wrote:
In article <e9cn3k$6lr$1@news.Stanford.EDU>,
Seungbeom Kim <musiphil@bawi.org> wrote:
Boost::scoped_ptr is nice for things like the pimpl idiom,
where you don't want to share. [...]
In practice, I've found relatively little use for shared_ptr,
although I use auto_ptr rather regularly, and occasionally
scoped_ptr. [...]
That makes me wonder why scoped_ptr wasn't introduced into
TR1; I really miss it. Do you know any reason it was omitted,
or any progress going on with regard to that?
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/wg21/docs/papers/2005/
n1856.html#20.4.5
%20-%20Class%20template%20auto_ptr
I've not had the time to read it in detail: if the goal is to
provide the same functionality in a cleaner manner, why not?
But the basic functionality of transfering ownership is useful.
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).
What's the different for a pointer?
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).
I'm not sure I understand. I'll have to read the article, but
the semantics of boost::scoped_ptr is unacceptable in the cases
where I use std::auto_ptr. Ownership transfer is essential.
(It's not a question of who deletes the object---I use the Boehm
collector for that. But on my machines, accessing an auto_ptr
after ownership has been passed off gives an immediate core
dump. Which is what I want.)
Thus I'm personally lacking motivation to have a scoped_ptr in
addition to unique_ptr.
The motivation is simply that they have different semantics. I
use the Boehm collector for memory management, but I still make
extensive use of smart pointers, for special semantics: once
I've given you this pointer, I cannot access it any more, or the
object pointed to is mine, mine, mine, and nobody can even copy
my pointer to it.
Fwiw, here:
http://home.twcny.rr.com/hinnant/cpp_extensions/unique_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).
Well, there are definitly contradictory use cases. In a pimpl,
I don't want to be able to copy the pointer; if I accidentally
copy it, I get a compile time error. When passing pointers to
objects between threads, I want to be sure that the thread
having passed the object can no longer access it. Both
requirements are, as far as I can see, incompabible with one
another, and both are incompatible with allowing containers of
the pointers.
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).
I'll read the paper first, but off hand, I see several
incompatible requirements. Or does the pointer uses some sort
of policies to determine its behavior.
--
James Kanze kanze.james@neuf.fr
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]