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.

[Alf P. Steinbach]

On Mon, 20 Oct 2003 04:03:09 GMT, gr**********@pa cbell.net wrote:

Yes, but returning a pointer from foo is a bad progamming practice.
Why don't you just say that auto_ptr is deprecated ?

Each of your sentences parse as english, but neither is meaningful
to me (as far as I know it's never been regarded as bad practice to
return pointers from functions, and as far as I know std::auto_ptr is
not deprecated and has not been suggested for deprecation), and
furthermore, to me they seem mutually contradictory.

What is it you're trying to say?

[Karl Heinz Buchegger]

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

void bar()
{
std::auto_ptr<L argeObject> 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.
Yes, but returning a pointer from foo is a bad progamming practice.

Says who?
Sometimes you don't have a choice.
Why don't you just say that auto_ptr is deprecated ?

You are concentrating too much on returning pointers.

void bar( int Type )
{
Obj* pObj;

pObj = Factory.CreateO bject( Type );

// do something

// object no longer needed, delete it.

delete pObj;
}

Now lets say, that the part // do something is rather complicated and there
is a chance that things might go wrong. You insert some tests and do a return.
But when doing so you must not forget do delete the object given to you
from the factory.
void bar( int Type )
{
Obj* pObj;

pObj = Factory.CreateO bject( Type );

// do something
...
if( SomeTest ) {
delete pObj;
return;
}

if( SomeOtherTest ) {
...
while( ... ) {
if( AThirdTest )
return;
}
}
// object no longer needed, delete it.

delete pObj;
}

So you see the big? Deep inside the while, there is an if which returns. It happened
to me, that I forgot to delete pObj, because I am human :-)

An auto_ptr saves me from all of this. I don't need to remember to delete pObj, it
is done automatically for me. For the very same reason that you use vector instead
of dynamically allocated arrays, you use an auto_ptr when you must use a pointer, to
free yourself from human errors and to easen maintenance (who says that this test
was there in the first place. It could have been added weeks later).

--
Karl Heinz Buchegger
kb******@gascad .at

[Karl Heinz Buchegger]

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

On Mon, 20 Oct 2003 02:11:56 GMT, Howard Hinnant <hi*****@metrow erks.com>
wrote:

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.

And that's exactly the problem.

-Howard

Why dynamic allocations in exceptions sensitive code ?

Every code is exception sensitive, except when written explicitly otherwise.
auto_ptr *is* a tool for taking care of exceptions.

--
Karl Heinz Buchegger
kb******@gascad .at

[Rob Williscroft]

lilburne wrote in news:bm******** ****@ID-203936.news.uni-berlin.de:

[snip]

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;
}

std::vector< T > is not a large object typicaly its the size of
3 pointers (12 bytes on my machine). The T's that it containes
are held in storage provided by std::allocator< T > which in turn
get its storage from operator new(), which allocates memory from
free storage aka the heap.

Note also the above example should benefit from NRVO so it should
perform as well as ( and some times better than ) this:

void calculate_some_ geometry( vector<Point3D> &geometry )
{
// do something that adds lots of points to geometry
}

The situation in wich it can perform better is:

vector<Point3D> geometry( calculate_some_ geometry() );

There is no array version of std::auto_ptr<> , but then we have
std::vector<> so we don't need it :).

Rob.
--
http://www.victim-prime.dsl.pipex.com/

[grejdanospam]

On Mon, 20 Oct 2003 04:15:23 GMT, Alf P. Steinbach <al***@start.no > wrote:

On Mon, 20 Oct 2003 04:03:09 GMT, gr**********@pa cbell.net wrote:

Yes, but returning a pointer from foo is a bad progamming practice.
Why don't you just say that auto_ptr is deprecated ?

Each of your sentences parse as english, but neither is meaningful
to me (as far as I know it's never been regarded as bad practice to
return pointers from functions, and as far as I know std::auto_ptr is
not deprecated and has not been suggested for deprecation), and
furthermore, to me they seem mutually contradictory.

What is it you're trying to say?

Hi,
A little bit more to parse. Look at the original post. Instead of dynamic
allocation of a single object hold by an auto_ptr we could always use an
automatic variable, maybe inside a template.
auto_ptr holds a single object, the code that uses it does not really use
polymorphizm - because the object is single.
Template is better solution then auto_ptr, also much faster.
--
grzegorz

[Thore B. Karlsen]

On Mon, 20 Oct 2003 11:25:12 GMT, gr**********@pa cbell.net wrote:

Yes, but returning a pointer from foo is a bad progamming practice.
Why don't you just say that auto_ptr is deprecated ?

Each of your sentences parse as english, but neither is meaningful
to me (as far as I know it's never been regarded as bad practice to
return pointers from functions, and as far as I know std::auto_ptr is
not deprecated and has not been suggested for deprecation), and
furthermore, to me they seem mutually contradictory.

What is it you're trying to say?

A little bit more to parse. Look at the original post. Instead of dynamic
allocation of a single object hold by an auto_ptr we could always use an
automatic variable, maybe inside a template.
auto_ptr holds a single object, the code that uses it does not really use
polymorphizm - because the object is single.
Template is better solution then auto_ptr, also much faster.

This makes even less sense! A template to hold an automatic variable?
auto_ptr does not use polymorphism? What? What?

Are you seriously saying that you can't think of a SINGLE time when you
might want to use auto_ptr or a similar smart pointer class?

--
Be seeing you.

[grejdanospam]

On Mon, 20 Oct 2003 10:12:22 +0200, Karl Heinz Buchegger
<kb******@gasca d.at> wrote:

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

Why dynamic allocations in exceptions sensitive code ?

Every code is exception sensitive, except when written explicitly
otherwise.
auto_ptr *is* a tool for taking care of exceptions.

Yes, but the code doesn't neccesery have to use dynamic allocation.
--
grzegorz

[tom_usenet]

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!

Use auto_ptr when you want to transfer ownership of pointers around in
an exception safe way. e.g.

struct Foo
{
void transferBase(Ba se* subelement);
//...
};

vs.

struct Foo
{
void transferBase(au to_ptr<Base> subelement);
//...
};

The second version enforces the transferral of ownership in an
exception safe manner.

Tom

[tom_usenet]

On Mon, 20 Oct 2003 11:42:06 GMT, gr**********@pa cbell.net wrote:

On Mon, 20 Oct 2003 10:12:22 +0200, Karl Heinz Buchegger
<kb******@gasc ad.at> wrote:

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

Why dynamic allocations in exceptions sensitive code ?

Every code is exception sensitive, except when written explicitly
otherwise.
auto_ptr *is* a tool for taking care of exceptions.

Yes, but the code doesn't neccesery have to use dynamic allocation.

Often it does (e.g. polymorphism or non-copyable objects).

Tom

[Karl Heinz Buchegger]

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

On Mon, 20 Oct 2003 10:12:22 +0200, Karl Heinz Buchegger
<kb******@gasca d.at> wrote:

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

Why dynamic allocations in exceptions sensitive code ?

Every code is exception sensitive, except when written explicitly
otherwise.
auto_ptr *is* a tool for taking care of exceptions.

Yes, but the code doesn't neccesery have to use dynamic allocation.

True.
But in case it has to, auto_ptr is there to help.

I am with you that dynamic allocations should be kept to
a minimum. But in real world programs it is often necessary
to have them and to deal with pointers. Eg. object factories
wouldn't be possible without them in C++.

--
Karl Heinz Buchegger
kb******@gascad .at