I cannot see the need for auto_ptr?!

[Jamie Burns]

Hello,

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!):

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!

Jamie.

[lilburne]

Jamie Burns wrote:

Hello,

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!):

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.

[Jamie Burns]

OK, so maybe I don't get why you wouldn't just allocate T on the stack? Is
that a bad thing to do? Why go out of your way to allocate on the heap if it
requires this type of attention to cleanup?

Jamie.

"lilburne" <li******@godzi lla.net> wrote in message
news:bm******** ****@ID-203936.news.uni-berlin.de...

Jamie Burns wrote:

Hello,

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!):

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.

[Thore B. Karlsen]

On Sun, 19 Oct 2003 22:00:22 +0100, "Jamie Burns" <se*****@email. com>
wrote:

OK, so maybe I don't get why you wouldn't just allocate T on the stack?
Because you want it to live longer than it would on the stack.
Is that a bad thing to do? Why go out of your way to allocate on the heap if
it requires this type of attention to cleanup?

Because it is very often the right thing to do.

--
Be seeing you.

[Jamie Burns]

But if I want it to live longer, surely I wouldn't be using an auto_ptr in
the first place (as it won't live past the end of the function that created
it) ?!

This is what I cannot grasp.

In terms of lifetime, T on the stack, and an auto_ptr<T> on the heap are the
same, no?

If so, that just leaves "Because it is very often the right thing to do",
which whilst I am sure is a sincere opinion, doesn't help me to understand.

:o(

Jamie.

"Thore B. Karlsen" <si*@6581.com > wrote in message
news:9v******** *************** *********@4ax.c om...

On Sun, 19 Oct 2003 22:00:22 +0100, "Jamie Burns" <se*****@email. com>
wrote:

OK, so maybe I don't get why you wouldn't just allocate T on the stack?

Because you want it to live longer than it would on the stack.

Is that a bad thing to do? Why go out of your way to allocate on the heap ifit requires this type of attention to cleanup?

Because it is very often the right thing to do.

--
Be seeing you.

[lilburne]

Jamie Burns wrote:

But if I want it to live longer, surely I wouldn't be using an auto_ptr in
the first place (as it won't live past the end of the function that created
it) ?!
Correct in general but you may want to return one, or you
may have to take ownership of a bare pointer returned from
some thing else.
This is what I cannot grasp.

Sometimes you have no option but to create something on the
heap (say the object is very big)

[grejdanospam]

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

Hello,

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!):

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!

Jamie.

You are right, auto_pointer is unnecessary.
One reason to use dynamic allocation is to allocate array of the size
known at the run time. std::vector deals with it.
Second reason could be to create an object which polymorphic type is known
at the run time. Then we could use :
template <class Type> type_dependent_ code(Type *p) {
Type data;
data.SomeFunc() ; };
void f() {
determine the TYPE;
type_dependent_ code(static_cas t<TYPE*>(0));
};
Returning pointer to dynamically allocated object is not a good idea
anyway.

--
grzegorz

[lilburne]

gr**********@pa cbell.net wrote:

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

Returning large objects on the stack is a worse idea.

// performance killer
vector<Point3D> calculate_some_ geometry()
{

vector<Point3D> geometry;

// do something that adds lots of points to geometry

return geometry;
}

[Thore B. Karlsen]

On Sun, 19 Oct 2003 22:20:42 +0100, "Jamie Burns" <se*****@email. com>
wrote:

But if I want it to live longer, surely I wouldn't be using an auto_ptr in
the first place (as it won't live past the end of the function that created
it) ?!

This is what I cannot grasp.

In terms of lifetime, T on the stack, and an auto_ptr<T> on the heap are the
same, no?

Yes, but you can return the auto_ptr, in effect just returning a pointer
instead of a copy-constructed object which might be expensive or (as is
often the case) impossible, or just not the right thing to do. Or you
can have a big object that is only allocated when it's needed, but whose
lifetime is longer than the scope you're in. Or you can take ownership
of an existing raw pointer and have auto_ptr wrap it and deal with
deallocating it.

If you don't understand why it's necessary, don't worry about it. You
will immediately see its utility once you start writing programs that
are sufficiently complex.

--
Be seeing you.

[grejdanospam]

On Sun, 19 Oct 2003 22:58:39 +0100, lilburne <li******@godzi lla.net> wrote:

gr**********@pa cbell.net wrote:

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

Returning large objects on the stack is a worse idea.

// performance killer
vector<Point3D> calculate_some_ geometry()
{

vector<Point3D> geometry;

// do something that adds lots of points to geometry

return geometry;
}

void calculate_some_ geometry(vector <Point3D>& v);

--
grzegorz