I've heard to use the heap/free store whenever possible when working with structs/classes and using the stack sparingly, but for a lot of open source C projects that use structs, they seem to use the stack. I don't really get it. Isn't that poor programming?
It isn't necesarily poor programming. The stack is just fine for a small, controlled amount of data. I use the heap when I don't know how much space I need, or the amount changes constantly. Structs are often used to pass multiple variables to a function, or just to group data together. In that case, I see no problem using the stack.
I see. What if I need to make several instances? Like a structure representing a character in a videogame. Such a structure would be used for possibly hundreds of such characters.
Yeah - I'd put that on the heap. Especially if you have any number of characters. For instance - an online game when people can join remotely and then leave whenever they want. You'd definitely need a dynamic structure on the heap.
I see. Well, the said open source projects I mentioned before included such games like the RPG type. So, that confused me.
It all depends on how much stack-space you actually have, and how much data you need to store.
In modern PC OS's such as Windows or Linux, the stack is a couple of megabytes or so, by default.
In an embedded system, the stack may range from a few hundred bytes to a few kilobytes.
So, the size consideration is that if you need some space that would be a few kilobytes, in a modern PC OS, then it's fine to put it on the stack. If you need a few hundred kilobytes, then put it on the heap, because you are going to use up too much of the stack if you put that much data on the stack.
If you are writing your game for an embedded OS (e.g. a mobile phone), then putting a few kilobytes of data on the stack may well be the equivalent of putting several hundred kilobytes on the stack in a modern PC OS.
It is also worth remembering that "out of stack" is almost certainly a catastrophic failure. Running out of heap is possible to recover from (at least to some extent - your application probably has to quit, but it can do so with at least some sort of message to the user to say what went wrong, rather than a OS-generated "bad memory access" error).
Another consideration is the actual life-time and usage of the data. If you have data that needs to persist from one function call to another, it is likely that you do not have any choice but to put it on the heap [or use global variables, but that is generally not a good option].
If possible and not likely to cause a problem, but data on the stack. It saves a lot of trouble, as there is no need to call a function to "get" the memory, and there is no need to free the memory later on - it is automatically managed by the language itself.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
You mention classes... and even games. Classes are only available in C++, and many, if not most, games are written in C++... unless you found one written in C.
So terminology clashes here... which language is it?
OK, so it applies to both C and C++, but still...
Originally Posted by Adak
