In the past whenever I needed to create an instance of a class I would use new to allocate it on the heap (except for stl classes, and math classes like vec3 and mat4).
However, I was just looking critically at some of my code and realized that technically I could just be making these classes on the stack instead. They’re not very big, don’t need to be modified outside of their current scope, etc. When I (occasionally) need to pass them to another function I can use a reference as easily as I could pass a pointer.
In the past I always defaulted to allocating on the heap, and only used the stack in certain cases, however now I’m wondering if it would have been better to default to allocating on the stack, and only use the heap when
- a pointer is really needed (ie the lifetime of the object to outlast the scope of declaration)
- the class or array is too big for the stack
- inheritance requires it (abstract base class/interface)
- something else?
Which also raises the question: how big a class is too big (roughly) to reasonably allocate on the stack? (assuming we’re working on, at minimum, smartphones, and going up to high end desktops) Am I just worrying unnecessarily about stack size constraints? (probably, as long as we’re not talking large arrays, and no class is going to be even close to a kilobyte)
I prefer to allocate on the stack, for two reasons. First, all else being equal, it is faster than heap. Also, the deallocation happens automatically, I don’t need to rememeber to
deleteit (of course, there areauto_ptrs and such to help with that).It is OK to pass a pointer to an object on the stack. Just make sure the user of that pointer does not access the object after its lifetime expires.
Only for really big things should this matter. You’ve probably got 1MB of stack, so you can put about 1000 1KB objects before there’s a problem.
Why would it?
The lifetime required of the object is longer than the lifetime of the stack frame. This is the principal reason to allocate on the heap.