So the X(T*) constructor first establishes ownership of the passed in ptr
with an auto_ptr. This is a no-throw operation, guaranteed to succeed.
Now the constructor goes about its other business. If anything following
throws an exception, the local auto_ptr destructor insures that the T* is
properly cleaned up. After construction is complete, the X officially
takes ownership of the T* by transferring it from the auto_ptr.

-Howard

Jamie Burns <sephana@email.com> wrote:

I realise that I just dont get this, but I cannot see the need for
auto_ptr.
As far as I have read, it means that if you create an object using an
auto_ptr, instead of a raw pointer, then the object will get cleaned up
when
the method/function ends. Isn't this what happens if you just declare an
object without using a pointer at all? Aren't these examples the same (I
know they will not be, but I am hoping someone may explain to me what I
am
missing here!):

The mechanism by which an auto_ptr ``transfers ownership'' to the
receiving call site makes it a very worthy addition to a C++ developer's
toolchest. (In particular, but realizing that threads are not defined
by the C++ language (hence the parens), it makes it easy to create a
pointer to an object in a routine that ``hands it off'' to a detached
thread).

Jamie Burns wrote:

Hello,

I realise that I just dont get this, but I cannot see the need for

As far as I have read, it means that if you create an object using an
auto_ptr, instead of a raw pointer, then the object will get cleaned up

the method/function ends. Isn't this what happens if you just declare an
object without using a pointer at all? Aren't these examples the same (I
know they will not be, but I am hoping someone may explain to me what I

missing here!):

void f()
{
T t;
t.SomeFunc();
} // cleanup when function ends

void f()
{
auto_ptr<T> pt(new T);
pt->SomeFunc();
} // cleanup when function ends

Wish I could see what is going on here!

What is required is that the object T is destructed when it
is no longer used and the memory it occupied is returned to
the system. With stack based objects (your first example)
this happens automatically when the object goes out of
scope, but with heap based objects (your second example)
this doesn't occur when a bare pointer goes out of scope.
auto_ptr being a stack based object gets destroyed
automatically, and in the process destroys the heap based
object T that the auto_ptr contains.

On Sun, 19 Oct 2003 21:40:55 +0100, "Jamie Burns" <sephana@email.com>
wrote:

I realise that I just dont get this, but I cannot see the need for
auto_ptr.

Ah, well, isn't that in the FAQ?

Checking...

Nope, not all, but the FAQ does explain the merits of std::auto_ptr in
the
presence of exceptions,
<url: http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.4>.

Okay, here goes, "std::auto_ptr for ze novice", by yours truly.

std::auto_ptr is currently the only example in the standard library of a
"smart pointer":



void bar()
{
std::auto_ptr<LargeObject> p = foo();

p->doTheFandango();
}

where the call to 'foo' transfers ownership up to the local
std::auto_ptr in 'bar', which guarantees deallocation even if, as Murphy
guarantees will happen, 'doTheFandango' throws an exception.

Returning pointer to dynamically allocated object is not a good idea
anyway.