Use of auto_ptr? I can't find one.

Hello,

i read a bit about stl::auto_ptr. Most tutorials show the big advantages refering to exception safety and avoiding memory leaks on an example like this:

Code:

---

void foo()
{
  T* t = new T();
  // exception
  delete t;
}

---

So here someone allocate heap in a function foo and deallocate it before t is going out of scope and the memory is lost.
The better way should be:

Code:

---

void foo()
{
  auto_ptr<T*> t( new T() );
  // exception
  // t is auto freed while going out of scope
}

---

My question what hold my awake this night is:
Why should someone declare a pointer T* and allocate heap, if he just delete it at the and of the same scope? The sens, for my understanding, of declaring a pointer and allocating heap is to append the live of a fraction of memory beyond the actual scope?!
So nobody would use the about example but just write:

Code:

---

void foo()
{
  T t();
  // exception
  // t is auto freed while going out of scope
}

---

or, if t should be available outside the scope of foo:

Code:

---

T* foo()
{
  T* t = new T();
  return t;
}

---

What did I get wrong, where is the reasonable sens of auto_ptr?
Thanks in advance.

Quote:

---

Originally Posted by pheres

Why should someone declare a pointer T* and allocate heap, if he just delete it at the and of the same scope? The sens, for my understanding, of declaring a pointer and allocating heap is to append the live of a fraction of memory beyond the actual scope?!

---

What if the object would be a really big one ? Say holding some 5 mb of Bitmap data. No chance to allocate that on the stack.
Kurt

Quote:

---

Originally Posted by pheres

The sens, for my understanding, of declaring a pointer and allocating heap is to append the live of a fraction of memory beyond the actual scope

---

No, because at the end of the scope in which it was declared, it will be destroyed. With or without delete. That is the same of every other variable.

A few reasons why you may want to allocate:

- When you don't know the dimensions of an array at compile-time
- When you want arrays to grow or shrink at run-time
- When you have a large object and don't want to waste precious and limited stack space
- When object creation decision is only known at run-time

Quote:

---

Originally Posted by pheres

Code:

---

void foo()
{
  auto_ptr<T*> t( new T() );
  // exception
  // t is auto freed while going out of scope
}

---

---

Mario seems to have answered your question quite well. I'll just point out a minor error in the example quoted here. The variable t should be of type auto_ptr<T>, not of type auto_ptr<T*>.

ok thank you all. one question remains:

Quote:

---

Originally Posted by Mario F.

No, because at the end of the scope in which it was declared, it will be destroyed. With or without delete. That is the same of every other variable.

---

fractions of memory allocated on the heap get destroyed?
why does something like this work then?

Code:

---

string* foo()
{
  return( new string("hello") );
}
int main()
{
  cout << *foo(); // prints "hello"
}

---

Quote:

---

prints "hello"

---

and also leaves a memory leak

> fractions of memory allocated on the heap get destroyed?

I mentioned object, not memory.

Memory contents is hardly touched when destroying or deallocating objects. If you save an address and then read it after the object has been destroyed, chances are you will see the same contents as before.

However, you could argue against me choosing the word "destroyed" on the previous post since destructors aren't in fact ran if my heap object goes out of scope. But I'm sure we understand each other.

Quote:

---

Originally Posted by vart

and also leaves a memory leak

---

uhm ok, but

Code:

---

string* foo()
{
  return( new string("hello") );
}
int main()
{
  string* s = foo();
  cout << *s; // prints "hello"
  delete s;
}

---

should do better i guess.

@mario:
oh I didn't thought on the physical bits in pc memory, more on the "allocated by the OS"-thing of memory which lives beyond the scope of all pointers pointing to it till one delete it. if that couldn't work there would also be no mem-leaks i think.

Quote:

---

Originally Posted by Mario F.

But I'm sure we understand each other.

---

I hope so, but I'm still not as familiar with c++ memory management as I wish, so I better ask twice :)

Quote:

---

Originally Posted by pheres

oh I didn't thought on the physical bits in pc memory, more on the "allocated by the OS"-thing of memory which lives beyond the scope of all pointers pointing to it till one delete it. if that couldn't work there would also be no mem-leaks i think.

---

I'm afraid you totally lost me there. I tried reading backwards and every other word too. Still didn't work ;)

So I hope what I'm going to say is the right interpretation of the above and I do helps dispel a few doubts you seem to still have:

The "allocated by the OS-thing" is the stack. This memory is what is used when you create an object as in int myobject;.

Also, a pointer can point to it, as you know.

Code:

---

int myobject = 13; // stack object;
int* p = &myobject; // stack object

---

The pointer p lives in the stack too. It is an object just like any other object. It has a value (the address of myobject) and it has an address itself that you could get with "&p". This address exists in the stack because that's where the pointer was created.

Dynamic objects on the other hand exist in the heap, as you know. A pointer is created that points to an unnamed memory location. That is the process of dynamic allocation.

Code:

---

int* p = new int(3);

---

p is a pointer that points to an unnamed memory location and that memory location is initialized with the value 3.

However, the pointer itself (p) is again created in the stack. the address of p exists in the stack. Not in the heap. It's the address p points to that exists in the heap.

ok that finally cleared things up (for today :-) ) thank you mario.