Here's my experience. Whenever a C++ programmer uses the word performance, it's never to describe using template-based generic data structures. I do it and the performance is fine, but the hard-core C++ programmers seem to hate STL.
Incidentally, I asked someone about memory management in an interview for a C++ position. He said he wrote his own memory manager (object pool, basically), and never even bothered to use "new" or "delete".
The reason you need to really care about memory management in game development is because most of the consoles don't have virtual memory. Once you run out (and you don't have that much), your game stops working. It's very similar to embedded system / real-time programming in this way. So you need to plan out how much space everything will use in advance, basically. Lots of fixed-sized buffers and pool allocators.
And the reason you don't use garbage collection is because real-time games can't afford a GC pause.
Comments
I have never seen anyone mix their custom memory manager with STL. Also, who said anything about Java or C#?
Right, they have a custom STL because they want to have their custom memory management.
Here's my experience. Whenever a C++ programmer uses the word performance, it's never to describe using template-based generic data structures. I do it and the performance is fine, but the hard-core C++ programmers seem to hate STL.
Incidentally, I asked someone about memory management in an interview for a C++ position. He said he wrote his own memory manager (object pool, basically), and never even bothered to use "new" or "delete".
Personally, I'm sticking to Haskell...
EASTL is essentially the reaction of a bunch of hard-core C++ programmers who hated all of the other STL implementations.
The reason you need to really care about memory management in game development is because most of the consoles don't have virtual memory. Once you run out (and you don't have that much), your game stops working. It's very similar to embedded system / real-time programming in this way. So you need to plan out how much space everything will use in advance, basically. Lots of fixed-sized buffers and pool allocators.
And the reason you don't use garbage collection is because real-time games can't afford a GC pause.
same thing we used to do on supercomputers, allocating memory is very expensive and surprisingly limited.
You also don't want your code to fail after weeks of runtime with an alloc error, if it's going to run out of memory you want it to fail at the start.
STL is more or less designed to support custom memory allocation, I would say that half of it's complexity comes from this.
Badly. Whoever thought putting it in the type of the container was a good idea obviously never actually tried to use it.