# STL for games, yea or nay? [closed]

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?

• The EASTL is a good reading open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html – Dr. Snoopy Jul 14 '10 at 22:24
• Yup, that's the one I meant by "used our own implementation". :) – munificent Jul 14 '10 at 22:48
• If you have the opportunity to locate and buy Best of Game Programming Gems, do it. There is an article title "Using the STL in Game Programming" by James Boer, ArenaNet, where he makes a really good case of using the STL. – chiguire Jul 15 '10 at 2:14
• Actually using Java without its standard lib is pretty conceivable, it's called J2ME :p – Bart van Heukelom Jul 28 '10 at 20:27
• Great question! – Alan Aug 10 '10 at 17:14

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.

• This is pretty solid advice. The "STL is slow" meme hasn't been true for at least five years and probably well longer. It will continue to live on, much like the "Java is slow" and ".NET is slow" nonsense, until it becomes apparent to everyone that it's no longer the case. The STL helps you write better programs; I'd go so far as to say that not using it, in most cases (aside from that 0.1% somewhere), is irresponsible. (The claims that it doesn't fit a given problem domain are often more of an indictment of the way the problem was tackled, not the STL itself. Fix your code, folks.) – Ed Ropple Jul 17 '10 at 22:01
• @Ed Ropple: I think that the issue is not that STL doesn't fit a given problem, the issue is that it fits too many problems which makes the code in it too complex. It is scary how people over-use STL and I think that is one of the cause why so many (including myself) refrain from using it at all. Like one example I saw not long ago where the question was how to get the largest out of 3 numbers, one of the answers was pushing them into an std::vector and then std:sort it. That's definetly forcing a solution that's unneccessary onto a very simple problem. – Simon Aug 13 '10 at 5:48
• @Simon: with all due respect, the last example is a sign of extreme cluelessness, and has nothing to do with STL... that person would do the same in any other language with lists that can be sorted. It's his thinking that is broken. – ggambett Dec 24 '10 at 13:56
• @EdRopple try to implement a STL parser for PPM image files (less than 100 lines of code in total if only targeting P6 or P3). Half of the resulting code is just for skipping comment lines because STL does not provide something like if(stream.nextCharacter() == '#') stream.skipLine(); – CoffeDeveloper Nov 14 '15 at 13:06
• @DarioOO I don't know that file format, but that's what stream adapters and filters are for. I wrote that comment five years ago, mind (and it occasionally keeps coming back!), but these days I write about anything that isn't super, super perf-critical in a functional, transform-based style and issues like the one you're describing fall out of the problem. I don't really care all that much about line count (and IMO nor should you), I care about correctness of implementation, then clarity, then performance, and then such things as code length. – Ed Ropple Nov 15 '15 at 17:24

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?

• I don't think anyone should have to justify why they shouldn't use STL. Also don't agree with the whole 'use it because they're smarter than you' argument. STL has been designed around a specific view of a problem domain, not just containers i.e algorithms, allocators, iterators, traits etc. That's fair enough but it's not the only way of looking at that problem domain – zebrabox Jul 17 '10 at 21:37
• So you'd rather home-rolled code than generally tested, strongly robust code? The problem domain is not all that different from project to project (aside from maybe embedded projects-- even consoles have decent STL implementations these days!). Regardless of game, your problem just isn't that different, and if you're making something you intend to ship, you have an implicit responsibility to write robust code. Is reimplementing the wheel going to lead to better robustness and flexibility? I lean toward "no". That it's not the "only way" doesn't imply it's not generally superior. – Ed Ropple Jul 17 '10 at 21:51
• I would say that gamedev is about making games, but OK. If your assumptions are so poor that you are getting drilled on that kind of resource allocation, then, yes, you need to step back and reevaluate them. But you can make blindingly fast applications that use the STL just as well--and, certainly, any other implementation--when you actually know what you're doing. Learning what you're doing > cargo-culting a refusal of the STL. Nobody said the STL is always the best answer. What I'm saying is that if you can't elaborate why it's not the best course, you should be using the STL. – Ed Ropple Jul 17 '10 at 22:12
• I don't think it's provocative at all--it's phrased in a way to make it stick in someone's memory, but it's an extremely conservative and straightforward stance. In short: the people who develop the STL are more knowledgeable and better-equipped than somebody who finds that they have to ask this question. If you have to ask somebody else whether the STL is appropriate or not, you almost certainly lack the domain-specific knowledge to adequately prepare a home-rolled solution. – Ed Ropple Jul 30 '10 at 16:55
• "It's going to be about as practically fast as the platform can allow". This is a definitive untruth, as many compiler vendors can't be bothered to rewrite the STL so that it would indeed squeeze the most performance out of the particular architecture. STL has no guarantee whatsoever about performance characteristics except for big O. O however might be as efficient or inefficient as the compiler vendor wants to make it. – Kaj Sep 5 '10 at 6:09

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.

• actually using large non pointer types in map is a good use case because stdlib maps have the requirement of not invalidating iterators which forces implementation into using pointers and individually allocated mapped elements. The best solution for games is using google::sparse_map or writing one's own. – v.oddou Jun 8 '15 at 6:36
• why not dense map? – CoffeDeveloper Nov 14 '15 at 13:08

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.

• Issues with STL's memory use and games can usually be solved with custom allocator classes. Indeed, at my previous job, our "custom" vector class was just a thin wrapper around std::vector that overrode the default allocator. – Blair Holloway Jul 14 '10 at 23:51
• @Blair Holloway: "The custom allocators are class-based, not instance-based. Allocators are required to construct and destroy objects as well as allocate them. This forces the mixing of two separate concepts: allocation and construction. These are just some of the issues with stl-allocators, unfortunately." The EA STL gives out several more valid reasons why the STD allocators are bad. It's not just "wether or not they can be overridden". – Simon Aug 12 '10 at 17:20
• @Simon - I won't argue that the STL's allocator system is perfect, because it's not. It did take us a long time to find a solution that work. What I'm saying is that in some cases, it is possible to get a workable, game-friendly solution using STL and a little work with custom allocators. – Blair Holloway Aug 13 '10 at 2:27
• @Simon - To elaborate: while the STL may be cumbersome, it's a very well tested and bug-free piece of code; if you can use it, you'll save man-hours having to debug a custom solution. My present job eschews the STL in favour of home-brewed allocators, and I've had to spend time debugging and refactoring some of that code, because it is not at the same level of maturity as the STL. – Blair Holloway Aug 13 '10 at 2:29
• @Simon: I'm a little late to the party here, but I'm curious if you would give a specific example of what you mean by that. What is a good example of solving a specific problem in a way that the STL is too general to solve efficiently? – BRaffle Aug 31 '10 at 20:29

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++.

• I disagree on the striving more towards C. The vast majority of games developers as well as SDK writers use C++. In fact the last major C user was id and even Carmack has gone over to C++ now ... – Goz Jul 17 '10 at 13:01
• Mr. Acton's comment seems sketchy. Generally speaking, the STL is a good fit for those problems. If you're trying to do something in such a way that the STL approach seems "wrong," it is probably a really good idea to re-evaluate your approach and see if you're actually doing it a smart way. In my experience, more often than not, you probably aren't. (It is vastly smarter, IMO, to solve a problem by strongly understanding it in the context of your tools than to throw away your tools just to redo it from scratch.) – Ed Ropple Jul 17 '10 at 22:06
• My experience with STL has been nearly opposite. It's efficient and time-saving. If you feel the need to roll your own template library or container library, then that's fine. But don't pretend that the STL (or boost, for that matter) is bad. I've used STL extensively on commercial iPhone, Nintendo DS, Wii, PC, Mac, and Xbox games. Every time I've been forced to use someone else's "better" library, I've found it lacking and buggy. – BRaffle Aug 10 '10 at 18:40
• It works as good on the DS as it does on any other platform I've used it on. I used STL all over the UI and AI code. The game was ds.ign.com/articles/832/832147p1.html. I was working at a small studio that was part of Amaze, which was part of Foundation 9. – BRaffle Aug 14 '10 at 1:07
• Mike is all about data. Looking at the data suggests the best method for transforming the data. Apply it on a large scale and you have programming. In this context his criticism makes a lot of sense. STL (and design patterns) suggest that rather than examining the data to come up with a solution, we examine the solutions in our bag of tricks to find one that works with the data. I don't mean to speak for Mike, but I believe he would suggest that this way of approaching the problem is backwards, and can potentially lead to inefficient or bloated solutions. – Dan Olson Sep 3 '10 at 6:47

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.

• map<> is almost never what you want to use for anything memory or CPU efficient within the context of a game. hash_map<> is almost always a better choice, although the performance of hash_map differs heavily with vendor. If you are building a game that is either for console or features scalable network play STL can absolutely be too slow or bloated for your purposes. – Ben Zeigler Jul 14 '10 at 22:03
• unordered_map<> is now widely available and has extremely strict performance requirements in the current TR1 draft. (To the point of overspecification I think - it even forbids open hashing, and while that's usually slower, I don't think it should be outright forbidden by the standard.) – user744 Jul 27 '10 at 6:30
• The STL offers algorithms as well as containers. There is never a reason not to use the stl version of an algorithm. For example, std::sort generally uses introsort underneath, blazingly fast and complex enough that you won't want to do it yourself. – deft_code Aug 27 '10 at 20:03
• truth is unordered_map either of C++11 or boost are both too slow, what you want is an open address hash map, such as google::sparse_map or your own. – v.oddou Jun 8 '15 at 6:42

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.

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.

• interesting ideas; what do you mean by "use class based new and delete" ? You mean, speed up a process by using objects already on the heap? – johnbakers Jun 18 '13 at 6:08

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.

• As mentioned elsewhere, you can provide custom allocators to the container classes - these could use freelists if you want (preallocated arrays). The array-of-structs vs struct-of-arrays is very dependant on what you're trying to do - there is no hard and fast rule about which one is better. – Skizz Jul 28 '10 at 14:19
• I appreciate your point that it's important to understand well the problem you're solving. But with respect, I still think I disagree with your conclusion. Every problem has usage patterns that cannot be expressed to custom STL allocators, but can be easily leveraged in a custom container, such as a fixed-block allocator implemented with a flat array. And applying a fixed transformation over an array of homogeneous types will very likely result in much better cache coherency than iterating over a vector of polymorphic types and invoking virtual methods. – Terrance Cohen Feb 20 '11 at 22:30

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!

• "Know when to trade performance for convenience". Yes. This sentence alone is as good an answer as any. Figure out what you need to achieve with your game, consult peers and decide if STL will help you get there or hinder you. I'd say if you're not looking to set the bar for next-gen graphics and performance with your game, STL will probably help you. – gkimsey Aug 3 '12 at 20:25

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?

• In practice, toward the end of a project, performance tends to be a critical problem. If you use STL, you have very little opportunity for optimization because it takes your specific applications and solves them in a general way. Solving specific cases in a specific way (and without dynamic memory allocation) is almost always higher-performance. – Terrance Cohen Jul 15 '10 at 1:33
• But if you don't want dynamic memory allocation, then you shouldn't be using the STL. That is sort of the point. Your own code is going to be no better, and could certainly be quite worse. The design decision to misuse the STL is the issue here, not the STL, its capabilities, or its perf characteristics. You're attacking the wrong part of the problem. – Ed Ropple Jul 17 '10 at 22:08

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.

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.

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.

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

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.

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.

• I agree 100% with the last part of your comment, but I'd go even further: if you can demonstrate conclusively why the STL is not a good option, don't use the STL. Otherwise, do. The cargo cult (everything from "oh, game developers use C++!" to "oh, game developers don't use the STL!") is unhealthy. I would, however, take a bit of an issue with your second paragraph: it's pretty unlikely that people who are still naive enough to think reimplementing the STL is a good idea will build a better vector than the STL folks. By the time you can do it, you no longer think you need to! :-) – Ed Ropple Jul 17 '10 at 22:03

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.

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.

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.)

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.

• While you're right, there can be a huge penalty for refactoring; so making an informed decision upfront instead of an arbitrary one will save you time in the long run. – Alan Aug 10 '10 at 17:29

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.