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

Question

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?

Answer 1

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.

The SC++L 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 SC++L or Boost provides. Such in-house libraries were often written long ago, when implementation support for the SC++L 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 SC++L as well, although much less so these days.

• Boost and the SC++L 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/SC++L/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 SC++L 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/SC++L have usually done so and reached that conclusion -- perhaps you will too, and perhaps not.

Answer 2

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!

Answer 3

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

Answer 4

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.

Answer 5

Tl;dr version:

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 boost a rather daunting task. Even if the technicalities of using boost aren't excessively complex, it is a massive library 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 right down to stupid little compiler flags you've got to set in order to make things compile correctly and play nice with C++11 and to use openSSL/zlib/etc with boost and so on and so forth.

However, make no mistake, once you can wield boost, you've gained a powerful weapon for rapidly simplifying and abstracting complex cross platform functionality. Just take boost::asio for example. You can write an immensely powerful, scaleable and rock solid cross platform asynchronous web server in just a few hundred lines. I've written two servers and a client using ASIO. The servers handle literally hundreds of thousands of queries from clients daily and not once have my servers crashed or malfunctioned or lagged out serving the clients. My server is running on linux, but thanks to boost abstracting away the platform specifics of networking, I could copy the source to a windows server, compile without any changes and have my server swapped out in 2 minutes. Boost not only makes things more convenient but she's rock solid.

As others have pointed out, larger companies are usually stuck with legacy stuff or like to roll their own which I completely understand.

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 do. So the idea is that if there is a need, there should be a highly performant, abstracted and therefore portable version of it in boost. Big companies contribute to boost, very educated people with impressive resumes contribute and maintain it, and when the latest standard of C++ what being developed, people looked to boost to see what parts of boost 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 very quickly. In the open source world those qualities can be difficult to come by.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.