STL for games, yea or nay?

  • STL for games, yea or nay? munificent

    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?

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

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

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

  • 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?

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

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

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

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

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

  • 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!

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

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

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

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

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

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

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

Related questions and answers
  • with c++. C++ was just the medium for learning. My opinion on the language? C++ is an amazingly diverse one size fits all language and its no surprise its around this long. My skills in it are basic... in the world. I'm OK at C++ but its one language I would really like to explore and make my primary language. (assuming there are jobs for grads in this area) This project will most likely define the career.... My primary language is Java and I've used it many times in the past. It is not a language I would say I love but it is easily my strongest. I've also used Ruby on rails for an internship i got

  • Are you aware of a complete (or almost complete) cross platform math library for use in OpenGL ES 2.0 games? The library should contain: Matrix2x2, Matrix 3x3, Matrix4x4 classes Quaternions Vector2, Vector3, Vector4 Classes Euler Angle Class Operations amongh the above mentioned classes, conversions, etc.. Standardly used math operations in 3D graphics (Dot Product, Cross Product, SLERP, etc...) Is there such Math API available either standalone or as a part of any package? Programming Language: Visual C++ but planned to be ported to OS X and Android OS.

  • or resources out there that i can use to avoid spending much of my time coding these now standard input devices/tecniques? ...Sorry for the ackward title, but i don't know what to call it exactly. I'm looking for code or libraries that allow easy creation of commonly used user input devices, and code/libs that make gaming... input to press buttons or drag objects in games has "Focuses" (like a textbox being able to gain focus and be typed in) Is compatable with SFML/Box2D and code for common game mechanics/controls

  • on exporting animation information, especially when the mesh changes its geometry? I would be thankful for advices that could point me into right direction. It would be nice to save some time instead of wasting it on incorrect approaches. I use Softimage as my 3D authoring tool. Target platform is OpenGL ES 2.0 running on mobile devices (iOS, Android). Programming language: C++. ...After careful consideration to use middleware, I have decided on creating my own 3d file format format to export meshes from 3D authoring application (Softimage) into my game. I will need to export

  • When it comes to mobile game development on iOS and Android NDK, some developers write their own C++ containers, while others claim that STL is more than adequate for mobile game development (For example, the author of iPhone 3D Programming uses STL rather than Objective-C in his examples. His defense is that STL is no slower than Objective-C). Then there are also mobile developers who abandon C++ entirely and develop games entirely (or mostly) in the C language (C89/C90). What are the benefits and drawbacks of each approach?

  • I have the book iPhone 3D Programming; this book taught be a lot about overall c++ iPhone application architecture and iPhone OpenGL ES. But a lot of the book is obviously about 3D, so most of the book wasn't that useful to me. I also have Game Coding Complete 3rd Edition; this book taught me a lot about game engine architecture but the emphasis is on c++ windows desktop game programming. I am looking for c++ 2D game engine architecture books. I'm not looking to use any frameworks; I want something more geared towards 2d c++ game engine architecture. Any suggestions? Thanks.

  • around and found this, which claimed that a lot of older developers didn't want to use STL because it wasn't mature enough. Also, older games AFAIK, used C rather than C++, which also doesn't have STL... is to say that he simply used arrays to store data, and use the naive approach to find data in it, meaning iterate through the array until you found what you wanted, assuming it wasn't in a performance... your using STL, you only need to declare the type as a list, rather than as a vector, and use iterators to loop over it, rather than looping an index. The advantages of using a linked list though

  • I'm new to Game programmming and SDL, and I have been following Lazyfoo's SDL tutorials. My question is related to time based motion and frame rate based motion, basically which is better or appropriate depending on situations?. Could you give me an example where each of these methods are used?. Another question I have is that, in lazyfoo's two Motion tutorials (FPS based and time based) The time based method showed a much smoother animation while the Frame rate based one was a little hiccupy, meaning you could clearly see the gap between the previous location of the dot and its current

  • I'm making a GUI API (in C++) for games which uses Allegro 5 as a backend. I looked at how GuiChan works and noticed that they intend for the user to override the paint event and do all the drawing yourself. Since I felt that in general, there's a decent standard to how widgets behave, I have a static theme class in each widget class (static ButtonTheme buttonTheme; etc) and the parameters set in that theme are used to construct that widget (from there, the parameters can be changed individually for specific widgets). These sorts of things are: padding, font color, border color, is drawing