Hacker News Reader

Comment by nanny | Hacker News Reader

Honest question: why wouldn't someone want to use STL containers?

Because someone might require different tradeoffs than those that were chosen by the STL's designers, such as in game development.

Which is why EA created the EASTL: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227...

Do note that some of the issues with STL as pointed out in the link above got improved upon as both implementations and compilers improved.

I use STL now, but in the past I've seen several reason not to.

Compiler support hasn't always been there, especially on embedded systems with old or poorly supported compilers.

Strict control over memory allocation hasn't always been possible with STL, and it's still not very convenient if/when you need your own allocator, e.g., embedded systems, console games.

And this isn't true any more, but I still remember what the error messages used to look like more than 15 years ago. Sometimes a single error exceeded the maximum output length for error messages in whatever compiler I was using, probably Microsoft's, and you couldn't actually see what the problem was. That left me with impressions of STL that took a long time to recover from.

A bit of the no one ever got fired for buying IBM. By using the STL containers you can quickly learn a not great, but not horrible API and have a good chance of it being around down the road, your stuff will still compile, api wont change and it might be available on other platforms.

Honestly, the API doesn't seem that bad when you understand what it's trying to achieve. There are some hairy areas though (dealing with std::bind many years ago comes to my mind, but I didn't understand back then that they were basically trying to shoehorn half of Common Lisp into C++).

They aren't always the right tool for the job. Maps allocate every node separately (c.f. Boost Intrusive). Vectors don't generalize to multiple dimensions efficiently. Lists for a long time had only the doubly linked type. Vendor specific hash tables had O(n) erase by iterator. Strings are not part of the STL strictly speaking, but anyway they have had varying performance and design characteristics on different platforms...e.g. short string optimization.

GNU pissed me off in the latest long-awaited ABI break by making std::string a whopping 32 bytes on 64bit platforms, yet only supporting 16 bytes inline for SSO. Their argument is it takes no more memory because std::string always allocated at least that much anyway, but it bloats structs and classes unnecessarily, and every single other vendor does it better.

I don't think you can blame the C++ standards committee for vendors creating shitty implementations.

At the moment, unless you're exposing an object via a public API, I recommend using boost::string and boost::multi_index for hash tables. In public APIs expose a good old fashioned char*,size_t pair, or copy to a std::string.

Because they're well designed, good enough 90% of the time, safer than writing your own, and easier than finding and integrating another library.

Once I was handling a big data set for natural language processing. It's big enough it nearly ate all my memory and was somewhat slow if I remember correctly. Then I switched to a C-based toolkit, memory usage dropped significantly. I never knew STL overhead was high until that point. Yeah STL is great, but for big data, maybe not.

We worked on a game that was being released simultaneously on 6 different platforms. STL was out of the question, too much overhead, we wrote our own containers for pretty much every single platform.

Reply on news.ycombinator.com