is there a real difference other than just using the '->' operator than '.'
and/or is there an advantage or a better practice of doing wt ever im doing.
thanks,
mahertamim
I think what you're really asking is the relative advantages and disadvantages of making things on the stack (as in your first example) or on the heap (as in your second example).
Yes, there really is a true advantage.
If you make it on the heap, using new, it will exist until you deliberately deleteit. So long as you don't lose the pointer to it, you can hand it around various scopes and functions, knowing it will still be there.
If you make it on the stack, it will be destroyed as soon as you exit that scope.
Sometimes, you will simply not have a big enough stack to make an object (big arrays are a common victim of this) and you will have no choice but to create the object on the heap.
a better practice of doing wt ever im doing.
That's very difficult to answer, given that we don't know "wt yr doin".
That's very difficult to answer, given that we don't know "wt yr doin".
im just trying to use a class, thought that was implied, sorry
and see if there was a true difference either performance wise or if there was a common/ suggested way
- Allocation on the heap is not as cheap as allocation on the stack.
- As Moschops said, objects on the stack must be smaller, for variety of reasons (cost of copy construction, locality of reference, stack overflow, etc.)
- In the current standard, variable-sized arrays are not supported on the stack. They will be in the next standard, but see previous point.
- Using pointers and references can remove compilation dependencies and consequently reduce the compilation times.
- Objects on the stack are cleaned-up automatically in case of exceptions. Something to compensate can be provided for heap allocated ones with RAII, reference counting, object hierarchies, or with some other form of garbage collection.
- Objects on the stack tend to be closer to each other in memory, and this helps caching and paging.
Regards
EDIT: In response to your last post - there is nothing truly conventional about programming ;)