Objects, or pointers to objects?

Hi people,

I'm coming from a Java background here, and I've learned that in C++ it is possible to have both objects, and pointers to objects. For example, for a class called Cat:

Cat fluffy; // An object.
Cat *tinkles = new Cat(); // A pointer to an object.

My question, then, is there any disadvantage or advantage to one or the other? In Java, you essentially only have pointers to objects, and that seems to work fine. My C++ book doesn't seem to give a preference one way or the other...

Thanks,

Just

I believe the benifit is that when you declare an object of a class with a pointer, it is done at runtime and not at compile time. This, I believe, lowers the size of your executable.

I could be way off here.

Zen would know this...

Well actually it speeds up data transfer;

Cat fluffy; // An object.
fluffy = new Cat; //actually creating the object on the heap

and would be referenced by;

Cat* tinkles = &fluffy;

with the "&" meaning the address of.

the flowing does nothing;
Cat *tinkles = new Cat(); // A pointer to an object.

just to clear a few things up....

You can declare an object to be on the stack or on the heap.

on the stack.....

use a local variable.....

class A {};

void function()
{
A myA;
// myA is a local object and so will be on the stack
}

on the heap.....

must use a POINTER.

class A{};

void function()
{
A* pMyA= new A;
// pMyA points to an A object which has been constructed on the heap.Do not lose this pointer.It is the only way to delete that object when finished with.

// do stuff with pMyA

delete pMyA; // free the memory when finished with
}

do not do this....

Cat fluffy; // An object.
fluffy = new Cat; //actually creating the object on the heap

that might work in java but not c++

new is an operator that returns a void* pointer. You cannot assign an object to a pointer to object without some form of reinterpret_cast()

Quote:

---

My question, then, is there any disadvantage or advantage to one or the other?

---

It's quicker to allocate on the stack, so unless you need dynamic allocation (where you don't know how many objects you'll need until runtime) or you need to keep an object around after it would have gone out of scope using the stack (beware of memory leaks), then you'd want to use your first example.

Allocating stuff on the stack disregarding how much or how many just takes max one clock cycle on Intel's processors and it generates much smaller code (3 bytes compared to the new operator calls and pushes and stuff). Allocating stuff on the heap takes several clockcycles. Maybe hundreds. I haven't measured.