Why don't C++ Game Developers use the boost library? [closed]

So if you spend any time viewing / answering questions over on Stack Overflow under the C++ tag, you will quickly notice that just about everybody uses the boost library; some would even say that if you aren't using it, you're not writing "real' C++ (I disagree, but that's not the point).

But then there is the game industry, which is well known for using C++ and not using boost. I can't help but wonder why that is. I don't care to use boost because I write games (now) as a hobby, and part of that hobby is implementing what I need when I am able to and using off-the-shelf libraries when I can't. But that is just me.

Why don't game developers, in general, use the boost library? Is it performance or memory concerns? Style? Something Else?

I was about to ask this on stack overflow, but I figured the question is better asked here.

EDIT :

I realize I can't speak for all game programmers and I haven't seen all game projects, so I can't say game developers never use boost; this is simply my experience.

Allow me to edit my question to also ask, if you do use boost, why did you choose to use it?

• Feb 24, 2011 at 17:30
• Would it be fair to say that "Boost" is far too large a collection of libraries to make "use boost" or "don't use boost" a fair choice? Even Google restricts to a small subset of "boost" in their standards I believe. Aug 11, 2011 at 22:35
• Game binaries are already massive enough. Jul 21, 2012 at 2:18
• @Tetrad STL is not boost, and STL is heavily used in gamedev. Mar 6, 2013 at 17:02
• I really don't see where the question is "not constructive", this would need explaining. Oct 14, 2014 at 5:13

Some developers do, some developers don't (in games and elsewhere). It depends on what the needs/requirements of those developers are, and what existing technology they have to leverage.

C++'s standard library is often given the same treatment, and people often wonder the same thing you are wondering about it, too. Most of the reasons are similar, for example:

• A developer may already have an in-house library of functionality that provides the same services that the standard library or Boost provides. Such in-house libraries were often written long ago, when implementation support for the standard library was weak and Boost was basically non-existent, so they more-or-less had to be written. In this scenario, it's usually not really worth transitioning away from the in-house functionality -- it would be a major porting effort that would destabilize a lot of code, and provide almost no benefit.

• A developer may be working on platforms where compiler support for the advanced C++ techniques leveraged by Boost are not well supported, such that the Boost code doesn't compile at all or performs quite poorly. This applies to the standard library as well, although much less so these days.

• Boost and the language's standard library are general purpose, and while that is fine and good for most applications, sometimes a developer has specific needs that can be better addressed by more specialized containers.

I think the above are two reasonable reasons, although there are certainly others. You have to be careful though because many reasons for avoiding Boost, the standard libraries, or whatever boil down to "not invented here" syndrome, which can be an indication that the reason isn't very well grounded in practical realities.

Also remember that the needs of a large-ish studio are usually very different from the needs of an individual developer. For example, an individual developer probably has less legacy code floating around to maintain and so perhaps porting from a home-grown version of the Boost or standard library functionality will not be as big of a time sink and will save that developer from having to maintain that code as extensively in the future -- thus invalidating my first bullet point.

In the end, it is all about evaluating your requirements and time investiture against your desired goal and determining which option meets your needs the best. Developers who aren't using Boost or the standard library have usually done so and reached that conclusion -- perhaps you will too, and perhaps not.

• Another point - some companies don't use Boost because of it's negative impact on compilation speed in a highly interative development environment. Dec 29, 2014 at 2:36

Edit Coming Back to This Question After A Few Years
Having continued to use more and more boost libraries, I thought I'd update this question to give a solid case for why you should use boost when the description of the product matches your desired functionality. This will convince even nay-sayers. Download openSSL, try to make a client and server application with it. Now try and make that work on every platform. Then, download and use boost::asio::ssl to make the same application. If you're not convinced that boost is the right place to look for clean, well optimized, peer reviewed, cross-platform code, this simple exercise will convert you.

Tl;dr version:

In my opinion, you don't see a ton of indie or small to mid size development firms using boost because it's a massive and powerful wild beast that isn't easy to tame and you're basically on your own when trying to learn how to use it. The documentation is lacking in a few ways (see long version) and "the community" around the project either seems to be missing, scattered or inactive (compared to other projects).

Very Long Winded Version:

I realize there is already an accepted answer but as someone who actually uses boost in nearly every project I do, I thought I'd post an answer.

I remember when I first got poking around in boost and honestly I had no frigging idea what was happening. Boost is not very well documented at all. People might disagree with me on that I'm sure because there are tons of snippets of example code and a comments and such, but it is all very cold and vague as well as difficult to navigate.

Also it seems difficult to find any place where you feel like you've found "the community" around the project. In fact the community seems non-existent, or nomadic. Unfortunately even their mailing list has been trolled by so many leech sites that you can go down this rabbit hole always looping back around to where you started.

These two factors make learning to use boost libraries a rather daunting task. Even if the technicalities of using boost aren't excessively complex, it is a massive set of libraries and staring it down when all you're armed with is a few code snippets and scattered pieces of the mailing list from the darkest corners of the internet... well you get the idea.

I got into tinkering with boost around version 1.45 and it's only now in version 1.52/1.53 that I feel comfortable enough to use it in production. There are so many things to get used to and remember, even simple things like how you've configured boost and remembering that configuration, because how the libraries are built and function can vary wildly based on your preferences at compile time due to how customizable things are.

However, make no mistake, once you can wield boost, you've gained a powerful weapon for rapidly building solid, cross-platform programs. Just take boost::asio for example. You can write an immensely powerful, scalable and rock solid cross platform asynchronous web server in just a couple hundred lines. I've written multiple clients, servers, proxies etc over the years with just a few hundred lines of code each that have yet to fail me, and can port them from platform to platform in minutes.

As others have pointed out, larger companies are usually stuck with legacy stuff or like to roll their own which I completely understand. There is also this really silly thing I've heard of and encountered where dev leads and or project managers forbid using boost because it's "too big". My guess is that they believe that boost is 1 single library or they've never heard of BCP.

As for WHY I choose to use boost

I'd say I use it because as you imply in your question, it's "the" C++ library. Boost is viewed in the C++ world as the swiss army knife of things that eventually you're going to need to use. So the idea is that if there is a need, there should be a highly performant, and portable version of it in boost. Big companies contribute to boost, very educated people with impressive resumes contribute and maintain it, and when a new standard of C++ is being developed, people usually look to boost to see what parts of it should become ISO standardized C++.

So if I need to add some functionality that there is probably an existing library for, the first place I'll look is boost just because I'm pretty safe in betting that it's pretty well optimized, portable, it will be supported and maintained for a very long time and bugs will be found and dealt with. In the open source world those qualities can be very difficult to come by.

• Very right as for documentation. For example, Boost.asio doc's will explain how to write an http server in surprisingly few lines, which is great if your game uses http (or any other vanilla TCP protocol for that matter) but it becomes much more difficult if you wish to use a custom protocol or proprietary network library. It took me 20 min to understand how to create a websocket server using boost.asio, but weeks to understand how to use ENet (enet.bespin.org) via a custom boost.asio io_service. Oct 13, 2014 at 21:54

We used a bit of Boost back at our old workplace. The main reasons for mostly avoiding it and limiting its use were:

• compile times - some of it is very slow to compile, and you end up being reluctant to have boost #includes in any of your headers
• complexity - it's not well known by most game developers and so makes for unreadable code
• performance - some of the concepts perform slowly by default, eg. shared_ptr
• boost::shared_ptr? how so?
– Tili
Jul 25, 2012 at 16:54
• If I remember correctly, it allocates the reference count on the heap somewhere. This is very bad for cache coherency during use and also means double the allocation and deallocation time at the start and end. Jul 25, 2012 at 17:03
• (Worth adding that use of make_shared can alleviate the problem.) Nov 22, 2012 at 18:35
• I think this answer is fairly clear that there are more reasons people avoid it than just to dodge one or two bad classes. Apr 17, 2015 at 8:57

Same thing is (was?) being said for the "more standard" STL. This article talks about EASTL, an in-house rewrite of (parts of) STL by Electronic Arts to accomodate the needs of game development which are rather different than those of "more generic" application development.

So, maybe, someone somewhere is re-writing (parts of) boost to accomodate their needs in game development!

• +1 for the article. I think this answers the question beautifully. Feb 24, 2011 at 17:05
• My experience is that the more portable your codebase becomes, the more you end up rewriting "standard" components, like STL. Feb 25, 2011 at 21:05

I hang out at StackOverflow and don't use boost. I will add my reason, because it is one not mentioned yet.

Boost has many great ideas, really. I like to look at what they have done and try out new things and ideas. They are great, because it is breeding ground for many C++ improvements.

But the boost is a very unwieldy beast for many reasons. One of the reason is that they need (want to) to be compatible on virtually any compiler with any quirks. As a result they need to employ many tricks, such as MPL to pull it off. For example (a long time ago) I wanted to use their shared_ptr, getting it to run meant I need the sources and libraries of what felt like 90% of boost. I ended up writing my own; 50 readable lines of code. (My requirements where stricter, like no weak_ptr or thread safety.)

Often you need a really small subset of boost, but integrating the entirety of boost is just not worth the hassle.

Edit:

Just to make is clear, since it appears not to have come over clearly (i.e. downvote). I use do use third party libraries. But in most cases, all things being equal, integrating a third party library or boost, the other third party library is quicker and cleaner. The remaining is done in "2h" finger exercise. I do take a very hard look in the build it or buy question.

• There are tools like BCP, y'know. Mar 6, 2013 at 15:11
• Are you implying that you don't have to maintain your own code? Also, I wish I was that good to be able to write all parts of boost I am using in 2 hours (which involves also testing them on all build targets I am going to use, and writing tests). You must be a really fast coder. Oh, and also "most of the useful bits" pretty much equals to "I can't C++" here, because standard still lacks a lot. Mar 6, 2013 at 15:29
• For starters a few features provided by boost, I found elsewhere in small well defined packages, for example sigc++. In many cases more elegant and/or more efficient. What I came to boost for most where features, such as threads, smart pointers and regular expressions, things that made it into the standard. Over the years I have acquired a collection of third party libraries and some code of my own. "I can C++" for over 15 years now, thank you very much. Mar 6, 2013 at 16:39
• @SeanFarrell you shouldn't be condescending. You say you've been doing C++ for 15 years and then in a snippy sarcastic comment to Bartek it seems you don't understand what Bartek means when he says "maintain" in conjunction with "packages". Maintaining doesn't mean fixing them. Simply updating to a new release or storing versions for multiple targets is usually what this means. Just FYI.
– user6484
Mar 6, 2013 at 17:16
• Sigh Boost also works out of the box, yet still you mentioned maintaining it. I fail to see your logic here. Mar 6, 2013 at 17:34

Who says they don't use boost? I've known one or two C++ engines that have used boost. I've never directly worked with them; but, that's mostly 'cause my experience lies in Unreal.

As for reasons I've encountered for not using boost, and these are subjective:

• We like rolling our own data structures specific to the platforms we're deploying to
• We like limiting the amount of non-internally developed code we have to use in our projects, especially when that external code is reliant on other externally developed libraries.

It basically boils down to: a general solution isn't always the "right fit."

I'm sure someone who's actually worked with the library could comment better.

• True, edited my question to account for this. Feb 24, 2011 at 16:33

In our case (not games), we have a great reason for not using boost (nor std): We have a lot of code that dates back a decade. According to the seniors, std and boost were either incomplete, full of bugs or just too slow for the high-performance things we require. So some base classes were implemented, using the same concepts (such as iterators) and often optimized for our algorithms. Nowadays, all three libraries (ours, std and boost) are very similar.

But do we want to port over all our code? Not really. I assume many other companies face the same dilemma. Either rewrite a lot of tested and working code or not use std/boost.

• This is true, and something I didn't think of, but I noticed that a lot of people starting on game development in C++ don't care to use boost / std. Sometimes I feel it's because learning boost is like learning a whole new language. Feb 25, 2011 at 16:28
• @James This is pretty much one of the biggest reasons. I posted an answer even though you've already accepted one just to give my perspective as someone who persevered through learning my way around boost, but not after being tempted to run away from it as well.
– user6484
Mar 6, 2013 at 7:58

I don't personally use boost or any other general purpose code when making games, because games are not generally general purpose. The kind of code you might need to implement a game is usually specific to game development, not always but like 98% (random figure) of the time. You can tack on that last few bits of code from boost or some other lib, but its probably better just to write out those little part you need here and there.

On a side note, I think that it is rather fun to write out your own code in c++, which is why I have never use boost or anything like it.

• It's fun, but boost is meant for people that want to do sh*t done, instead of reinventing the wheel. Mar 6, 2013 at 15:11
• This is my opinion, but it is a fallacy to say that "games are special". Yea, real time industry automation is also special. I do both and can attest, that the bits where boost would apply, very clearly are quite similar. Saying they are different is ignorance, because on the fringes they are very different but the core language use is same. A sort function is basically the same no matter what you sort. (Then again, just that you can, does not mean you would want to, see my answer.) Mar 6, 2013 at 15:15
• You can add the entire networking/multiplayer layer to your game using boost::asio and invent your own communication protocol for it. That is a 100% perfectly valid reason to use boost is any game you ever write that requires any kind of network related function. "Rolling your own" can be great when you're new and you need to learn. Nothing wrong with that. But at the end of the day I'm not going to waste time trying to write my own cross platform asynchronous communications layer when it's already been done and well at that.
– user6484
Mar 6, 2013 at 16:31
• @HaywireSpark There is no need to start insulting people. I read your post, and still disagree with you. Even if you go with "usually specific", that is entirely irrelevant. Almost everything in boost is designed to be as portable and mutable as possible. boost::asio is a very generic implementation and is not geared toward any specific way of network communication. I can't imagine any scenario where I'd have to say "gee, boost::asio just doesn't fit my networking layer model I better reinvent the wheel". Just saying.
– user6484
Mar 6, 2013 at 16:40
• @HaywireSpark sigh. Have a good day buddy. You should try to be more open to criticism. Being able to accept criticism is part of being teachable, and if you're not teachable you're never gonna learn a thing. I'm not picking on you. Every person that has posted on your comment has disagreed with you. That's usually a good indication that you've said something disagreeable.
– user6484
Mar 6, 2013 at 17:09

legacy in house libraries is not a factor... the main reason why anyone shouldn't use boost u other general purpose library is because they're not optimized speed and memory, tho i have to mention that Cryengine uses the STL but they compile it agianst an open source version called STLPort, so dont be afraid of using the STL, just implement your custom allocators and you'll fine. dont use boost tho.

• -1: For your belief that "Boost" is "not optimized speed and memory", when there are literally dozens of Boost libraries, all with varying degrees of speed and memory efficiency. Jul 25, 2012 at 0:29
• ... That actually is the reason a number of game developers avoid boost and even roll their own STL, along with the fact that the heavy template usage drive compile times through the roof. Especially keep in mind debug builds on MSVC, where you need the absolute minimum amount of abstraction and wrappers and genericism you can get away with, all of which are antithetical to Boost. The problem is not algorithmic, but simply that Boost was never meant for bare tithe metal speed. Nobody aside from game developers would want te trade offs that requires anyway. Jul 25, 2012 at 5:27
• @seanmiddleditch: My point is that there are many libraries in Boost. Some of them are faster and more memory efficient than anything you could code to do the same job, and some of them aren't. To denigrate the entire set of libraries for this is simply ignorant. Jul 25, 2012 at 18:51
• There aren't many game developers that can write a parser that is faster than Boost.Spirit. While there are many better (easier to use) options for parsing complete languages, Spirit is very fast at parsing well structured strings, even just converting strings to data types. The Boost.Xpressive library is also very fast for regex. Bear in mind that many of the people working on Boost are also people that work on the C++ standard committee, and they know how to get optimal performance out of C++ across platforms. Jan 23, 2013 at 17:29
• They often use template metaprogramming in ways that allow a large part of the work to be done at compile-time, instead of at runtime, which will beat the hell out of any of the low-level runtime optimizations that game developers are so proud of. I've seen some performance increases of over 50x when converting certain tasks from some common high-performance C libraries to use the Boost equivalents. Jan 23, 2013 at 17:36