Re: new and delete from different threads

Tamas Demjen wrote:


Here's a section from the tutorial with my comments inline:


I dispute your title. auto_ptr is a simple pointer for simple needs. As
Stroustrup says, it "isn't a general smart pointer. However, it
provides the service for which it was designed -- exception safety for
automatic pointers -- with essentially no overhead" (_TC++PL_, 3rd ed.,
sec. 14.4.2). IOW, it is not "wrong"; it's just different. Indeed, the
Boost documentation for their smart pointers says, "These templates are
designed to complement [not replace] the std::auto_ptr template."

In fact, I find it very useful for communicating transfer of ownership
without involving shared_ptr when the latter would add ambiguity and
unnecessary overhead. Here are two common uses:

 class A { /*...*/ };

 std::auto_ptr<A> CreateA()
 {
   return std::auto_ptr<A>( new A );
 }

 class B
 {
   boost::scoped_ptr<A> a_;
 public:
   B( std::auto_ptr<A> a ) : a_( a ) {}
   // ...
 };

The CreateA() function signature makes clear (and tries to enforce!)
that the user is responsible for deleting that pointer that is
returned, and if you happen to want to use the object in a shared_ptr,
conveniently there is a shared_ptr constructor for just that purpose.
Hence, the following line would work fine while still using the minimal
(i.e. zero-overhead) tool for the job since other users may have
different needs:

 boost::shared_ptr<A> pa( CreateA() );

In the case of class B, the use of auto_ptr makes clear that B is
assuming ownership of the A object passed to it. It could use
shared_ptr (but not scoped_ptr!), but that would be less clear if the
desired behavior of B is that it solely own that A instance. (I use
scoped_ptr as the member instead of another auto_ptr because the former
doesn't allow any copying, so the implicitly generated copy constructor
and assignment operator won't give me any hidden problems.)


First, this can be an advantage -- it just depends on the situation.
Second, the original instance is not "destroyed" (i.e. deleted).
Rather, the second instance of auto_ptr assumes ownership of the object
instance, and the first one no longer refers to it. Perhaps a better
word is "invalidated."


True, and that is also sometimes desirable. scoped_ptr fits the same
description, but it is also often useful.


True (if you replace "destroy the original copy" with "invalidate the
original auto_ptr"), but if you need to prevent accidental copying, you
should be using scoped_ptr. When the TR1/Boost smart pointers are
available, auto_ptr is most often used purely for *transferring*
ownership, not exception safety, ownership by a class, or copying
objects around. It could be better named, of course, as this bit of
history from the Boost docs relates:

"Greg Colvin proposed to the C++ Standards Committee classes named
auto_ptr and counted_ptr which were very similar to what we now call
scoped_ptr and shared_ptr. [Col-94] In one of the very few cases where
the Library Working Group's recommendations were not followed by the
full committee, counted_ptr was rejected and surprising
transfer-of-ownership semantics were added to auto_ptr."

As I've argued above, these transfer-of-ownership semantics are not
innately evil. They just must be used deliberately. When they aren't
desirable, a different smart pointer should be used instead.


No. First of all, it's okay to delete such a class if the destructor is
"trivial", and second, deleting a declared-but-undefined class instance
with a non-trivial destructor results in undefined behavior, which
could be but is not necessarily a memory leak. That is actually a
"problem" with the language, not just some compilers, and Boost uses an
"ingenious hack" (boost::checked_delete) to prevent the unintentional
deletion of a declared-but-not-defined class instance. It could be
added to auto_ptr, too, without breaking any existing, working code
(i.e. code that doesn't already result in undefined behavior), but I
don't know if that's in the plans.

Cheers! --M