views:

317

answers:

7

Possible Duplicate:
Why would you ever want to allocate memory on the heap rather than the stack?

Test2 *t2 = new Test2();
t2->test();

Test2 t3;
t3.test();

Why would I want to create a pointer object of type Test2? Why not just do non pointer version of Test2? Why would I want to do pointer objects?

Found answer here:

+4  A: 

If you need an object to outlive the scope it was created in, then one of the solutions would be to create it on the Heap. In which case you would need a pointer. There are other reasons too, this is the most common.

Another reason to use pointers is for "out" parameters. Granted you could use references, but many prefer to use pointers since it obviates the modification of the parameter at the call site. foo(var); vs foo(&var);

Also, pointers can be used to either pass or return an object which may or may not exist. For example: T *foo(); // returns a pointer to an object or NULL if none exists.

The list goes on and on really.

Evan Teran
Can you list some of the other reasons?
Not true. Object declared as `static Test2 t3;` in local scope will outlive the scope it was created in. Yet it is not created on the heap.
AndreyT
@AndreT: good point, I'll revise my answer.
Evan Teran
+2  A: 

Any type of dynamic data structures (lists, binary trees, stacks, etc.) must use pointers to objects.

Mashmagar
+9  A: 

The reasons to use dynamic storage include (but probably not limited to)

  1. Manual control of the objects lifetime - the object will live until you explicitly destroy it
  2. Creating as many objects as necessary, when the final number of objects is only known at run-time (like number of nodes in a tree or number of elements in an array).
  3. Run-time control of the object's type (like actual type of polymorphic object).

When it makes no difference, it is always better to create the object using your t3 method. Don't use dynamic memory unless you have to. But sometimes you really have to (see the reasons above).

AndreyT
+1  A: 

A common (but not required) implementation is that local variables are allocated on the stack. The stack is finite, and it is possible to have an object be too large to allocate on the stack.

Bill
+1  A: 

If you have a very large object (for example one with very large buffers as members), you may not want to allocate it on the stack, since stack space is limited, in that case you allocate on the heap with operator new.

jeffamaphone
Thank you; I'm a Java and C++ programmer but my classes never went over stack/heap...
+1  A: 

The main difference is where it lives in memory. The "non pointer version" lives on the stack, meaning it will be invalid once the function returns, while the "pointer version" lives on the heap, which means it will be alive and well until somebody calls delete on it. In general it is considered best practice to put objects on the stack whenever possible, and only on the heap when needed. A good example of needing the object on the heap would be something like this

Obj* f()
{
  return new Obj();
}

the new Obj() creates an Obj object on the heap and returns a pointer to it, which is then returned from the function.

This, for example, would NOT work

Obj* f()
{
  Obj o1;
  return &o1;  //BAD!!
}

Since the pointer value &o1 references memory on the stack, and f() is cleared off the stack at that point, who knows what will happen. Definitely nothing good.

Graphics Noob