STL for games, yea or nay? [closed]

Question

Every programming language has its standard library of containers, algorithms, and other helpful stuff. With languages like C#, Java, and Python, it's practically inconceivable to use the language without its standard lib.

Yet, on many C++ games I've worked on, we either didn't use the STL at all, used a tiny fraction of it, or used our own implementation. It's hard to tell if that was a sound decision for our games, or one simply made out of ignorance of the STL.

So... is the STL a good fit or not?

Answer 1

Back when I worked in professional game development, STL was too immature and bloated. But that was >10 years ago.

Now I work in military simulation, which has even tougher performance requirements (like the framerate can never go below some FPS). In military simulation STL is used all over the place.

Some of the people who tell you not to use STL use the argument that it's not always the perfect or even the best solution to the problem. But that isn't an answer to the question. The question should be: Is there something inherently wrong with using STL in games? I'd say no, STL is most of the time a better implementation than what a user would come up with on their own.

Just make sure you know how to use the STL, and use it in your game. Read some books and look at the implementation code in the STL you are using.

Answer 2

I would say that, off the top of my head, it is a better idea to use the STL unless you know exactly why you don't want to use it.

Here's the thing about the STL: it is developed by people who are smarter than you are. That's not intended to be offensive or anything, it's just that the STL is developed by people whose work is actually building the STL. It's going to be about as practically fast as the platform can allow and will generally be much more robust than a home-rolled solution (and this should be as much of a concern if not more than worrying about raw speed--because your game needs robustness a good bit more than you need speed; the latter is meaningless without the former).

The complaints that the STL enforces a "narrow view of the world" strike me as a little silly. They're containers. They have a limited set of operations because containers have limited sets of operations. What are you doing that doesn't jibe with this?

Answer 3

I've seen very few reasons not to use the STL for games.

For the memory allocation issues, many people don't know this but you can write custom allocators for your STL container classes. Allocators are basically policy classes you pass into your templates to determine how allocations are performed. Using these you can usually work around whatever memory issues are problematic on your platform of choice.

Of course, if you're using the STL and doing dumb things like maps of strings to large, non-pointer types, then you have bigger problems on your hand.

Answer 4

The default STL has a fair number of issues that make it difficult to use with games, especially when it comes to memory alignment.

A customized variant such as the EA STL is specially designed for games and can get you much better memory performance and console usability. It became open source in 2016, under a BSD-3 clause, with a repository on GitHub.

Answer 5

If you find yourself rewriting something that already exists in the STL, for any reason, stop. Use the STL.

The STL has been optimized over years of analysis and time, and it's a safe bet you're probably not going to write something that's more efficient. That's not to say you should use STL where a simpler solution may be possible (i.e. use an array when you have a known quantity of things, not a stl::list), but if you're writing your own implementation of a map (the basic data structure, not a game world map), you're doing it wrong.

Answer 6

Here is what Mike Acton (Engine Director at Insomniac Games of Spyro the Dragon, Ratchet & Clank and Resistance fame) had to say about this when asked here. Note he was asked about both STL and Boost in general as related to usage in game dev.

STL/Boost, does it belong into gamedev? If only parts of it, which ones?

You're asking about two different things here, right? STL and Boost, separately. But really, my answer is the same: There's nothing wrong with either one per se, but I discourage their use. Use of either encourages people to fit a solution to a problem rather than finding a solution to a problem. The solution should always be appropriate for the data at hand and the constraints of the hardware, etc. Both STL and Boost have an extremely narrow view of the "world" and their appropriate use is limited. Really, I discourage them because they lead programmers down the wrong direction right away, I often say if you feel like you need either one you probably don't really understand the problem that you're trying to solve.

I have also noticed that most pro game developers strive more towards C than C++.

Answer 7

Is STL a good fit for games? Definitely. Games are complex pieces of software, the STL provides features that help manage complexity, so it's good.

Is it a good fit for your platform? Not necessarily. If you're writing for a console then you have to be very careful about memory and cache usage. The STL doesn't make this very easy.

I think that all too often we mistake "games" for "high performance real-time games that run on embedded or bespoke hardware", but it's important to make a distinction. If you're writing a Windows game that isn't trying to run in fullscreen at a constant 60fps then there's no reason to avoid the tools that the standard library gives you.

Answer 8

I know this is very late to the party, but time changes and answers stay around. C++11 has pretty sweeping changes, many of which are to increase the performance of C++ and the standard library. It seems those who do not use the STL or Boost, tend not to keep up with new standards either, leaving the home spun solutions lacking important improvements, of course this is not always the case.

I've used STL on every project from the mid 90s to today, with the exception of a short time at EA. I think the anti STL side had some marginally rational reasons to not use it. Those are largely gone. Custom allocators are one solution, using reserve is another, and not passing things by value is a third, but these are pretty simple and any programmer should know these. More importantly though is the use of algorithms. Compiler writers know exactly what a for_each() does and can optimize the code. That cannot occur with a home rolled loop. for_each() on a const object is even better. Microsoft optimizes for_each in many ways including serializing. They also have the AMP library which has parallel_for_each(). If you get a chance, talk to compiler engineers about this. Console compilers are going to optimize what gets used, so it's a bit of a chicken and egg problem. Microsoft is going very heavy with C++11 and the next XBox will be no different. I have no idea about PS4, we haven't gotten one yet.

Custom allocators is one way to handle the memory issue, but another (often overlooked) option is to use class based new and delete. Huge performance increases can be had this way.

The notion that Boost and STL have a narrow view of solving problems is pure insanity. I'm stunned at how many things in the STL and Boost are customize-able through traits and policies. Look for case independent string compare as an example.

Regarding long link times and code bloat, the new extern template should help with this. Generally I find long compile times come from excess coupling and misuse of pch.

The most compelling reason to use STL over homespun is there are millions of people who can help you with the STL. As always, don't optimize prematurely and test, test, test.

Answer 9

This is a hot topic in game development. I personally don't recommend it, except perhaps for EASTL as mentioned above. I have two main problems with STL (technically "The C++ Standard Library", as STL is no longer the name) in games. 1) Dynamic memory allocation often wastes a lot of runtime in games when STL is used. 2) Use of STL encourages an array-of-structs approach to game architecture, whereas a struct-of-arrays approach is much more cache friendly.

Answer 10

It depends. How big is the project, what platform(s), and what is the timeline?

If you're working on a large project, on platforms with limited resources, with a significant timeline and budget, then you can save yourself a lot of trouble by avoiding the inevitable hell that will be looking at a half a million line code base that's littered with STL, can't keep a framerate above 30, eats enough RAM to fit several more assets, and takes 2 hours to build.

In other situations however, STL and even Boost can be very useful when applied appropriately. I've worked on titles that used a selection of STL/Boost, and were an absolute dream to code for: fewer bugs/leaks and easy to maintain code means more time coding fun new features! For hobby projects especially, that's a huge win in the motivation department.

Know when to trade performance for convenience!

Answer 11

IMHO I'd say it's a good fit since STL already works well and is optimized for the tasks it's made for. Besides, you're working on a game so, use the tools you have at hand that makes your life easier and your code less prone to bugs.

Why bother reinventing the wheel when you can be working on something else like the game's AI, user experience, or better yet; testing and debugging?

Answer 12

STL is absolutely fine for use in games, as long as you understand it well. Our engine makes pretty extensive use of it and it hasn't ever been an issue. I don't have any experience with console development, which may be an entirely different story, but it is well supported on all of the PC platforms (Windows/Mac/Linux).

The most important thing is to understand what the strengths and weaknesses of each container type are and pick the correct container for the job you are doing.

Answer 13

My former employer shifted from using a robust set of custom container classes to STL. Build times went up and ease of debugging went down, both pretty significantly. If we'd been starting from scratch, STL (perhaps better used) would likely have made sense, but it was never clear to me that we gained anything in switching to STL that would justify throwing out working, fast, debuggable code.

For my personal projects, whether STL fits or not depends on the project. If I'm trying to do some Mike Acton-style data-driven, memory-and-cache-access optimized work, I'll at least think about rolling my own custom data structures. If I'm prototyping some algorithms or gameplay and don't care about performance, scalability, target platform, etc. I'll automatically grab STL.

Answer 14

My 2 cents on this is that the STL works just fine. I've been developing a 3D game engine (not AAA quality, but advanced enough - scripted entity types, deferred renderer, integrated Bullet physics) for PC and I have yet to see containers become the main bottleneck. Incorrect 3D API usage and poor algorithms have been the best targets (determined by profiling!) every time I've gone in and tried to eek out a bit more performance.

Answer 15

I've built games using STL and I like it, and it seems to perform well.

Answer 16

Good question! A more specific question is what are some common requirements that a game would have that cannot be met with STL and Boost.

In my experience, the tight memory limitations of console hardware make any kind of dynamic sized container a bad idea regardless of how clever your custom allocator is. Containers that have no deliberate bounds encourage programmers to write code that does not constrain the bounds of their data sets. Depending on countless variables that are difficult to track you may exceed your memory limitations. I have a hunch that this is one of the primary causes of instability in modern games.

Additionally, overuse of templates can lead to very long compile times in a large code base, and will bloat the size of your executable so that it would no longer fit within the cache of, say, an auxiliary core on a ps3.

However, for PC-only development I think STL and Boost are very good. While general-case solutions are not always ideal, they are often good enough. Your first solution to a problem is almost never ideal, and you improve or replace the inadequacies until it is good enough.

Answer 17

The STL is a good fit for your game if the STL is a good fit for your game.

As with all technology choices made during development, you need to weigh up the pros and cons -- will rolling my own library give me more beneficial memory usage, performance, and productivity than simply using the STL? Possibly; though it's just as easy to create a vector implementation that uses more memory, is slower, and requires large amounts of maintenance to remain function compared to what already exists.

People should not avoid using the STL in their games because other people avoid using the STL in games; they should avoid using it if they've weighed up all of their options and they genuinely believe that another implementation will improve the quality of their product.

Answer 18

As with most questions the answer is never "yea or nay", black or white. STL is a good fit for some problems, using it for those problems should be fine. It's a mistake to assume it's useless, yet it's also a mistake to assume that it is appropriate to use in every situation.

The biggest issue to watch out for when using STL in game development is memory allocation. STL's default allocators don't seem to fit well into preferred allocation strategies for game development. Of course custom allocators can be used, but this makes the whole idea less appealing if you're considering whether to add STL to a non-STL codebase.

Add to this that if your codebase is non-STL, you may not have anyone familiar enough with STL or template concepts to implement the custom allocators correctly.

Answer 19

I think this discussion can be summarized as follows:

mediocrely written application-specfic code < well-written general purpose code < well-written application-specific code

Anyone whose home-grown solution would fall into category 3 surely knows the answer to the original question for their particular problem. The STL falls into category 2. So for someone who needs to ask the question, "should I use the STL", the answer is probably yes.

Answer 20

STL is all right for use on a PC, because its advanced virtual memory system renders the need for careful memory allocation a bit less crucial (although one must still be very careful). On a console, with limited or no virtual memory facilities and exorbitant cache miss costs, you’re probably bett er off writing custom data structures that have predictable and/or limited memory allocation patt erns. (And you certainly won’t go far wrong doing the same on a PC game project either.)

Answer 21

I think this question is really a larger unasked question -- should I use X in my Y? And the only way to really answer that is to try it for yourself. For every person you find that says that X works great, you'll find someone who says it's horrible. And both of them are right -- for their project.

The great thing about software, unlike most other disciplines, is that you can always change things later on if you find it's not working the way you would like it. You find out later that STL isn't working for you in this project? Rip it out, put something else in it's place. Don't like how you divided the duties among your objects? Refactor. Don't like that you used objects? Replace them with straight C methods. Don't like everything being stored in structs and methods to manipulate them? Replace them with C++ objects.

Answer 22

I say nay to the STL. My reason is quite simple:

1. You dont' need the STL to write games. Not even large ones.
2. STL dramatically increases your compile time.
3. Large compile time leads to less iterations over your development.

I hold iteration count to be of the highest importance, so I just stay away from the STL, and any other development technique that slows down iterations (like architecting for the sake of it, or script languages that need to be compiled).

Costly iterations lead to huge development teams of people trying to get stuff done with very little actually happening. I've seen it and heard it, and one of the culprits seems to be compile times for template libraries.