Hacker News Reader

Comment by ig1 | Hacker News Reader

A surprisingly large number of companies have their own STL implementations from Investment Banks to Telecoms companies. Often because they're doing funky things (often related to memory allocation) which would be outright impossible to do in languages like Java or C#.

View on HN

Not trying to argue with you, I'd just like to mention as a curiosity that you would be surprised by how much 'funky' stuff you can do in C#. It has pointers (not just references, but real C-style pointers), it can pin objects in the memory, etc. It's hidden from the sight of the regular programmer, but it's there and it's part of the language, none the less.

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.

Reply on news.ycombinator.com