Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
2  
related: gamedev.stackexchange.com/questions/268/… –  Tetrad Feb 24 '11 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. –  Dan Olson Aug 11 '11 at 22:35
    
Game binaries are already massive enough. –  Legion Jul 21 '12 at 2:18
    
@Tetrad STL is not boost, and STL is heavily used in gamedev. –  rootlocus Mar 6 '13 at 17:02
add comment

closed as not constructive by Trevor Powell, Sean Middleditch, Jimmy Shelter, bummzack, Josh Petrie Mar 6 '13 at 16:13

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

9 Answers

up vote 25 down vote accepted

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.

share|improve this answer
1  
Any links to SC++L info? Googling that term is a nightmare. –  Jari Komppa Feb 25 '11 at 21:08
1  
@Jari: S tandard C++ L ibrary. The STL is a large part of the standard library. Traditionally, many people referred to the standard library as the STL. This is technically incorrect and Mr. Petrie was being pedantic. –  deft_code Feb 25 '11 at 21:17
5  
If he's going to be pedantic, he should do it correctly: It's C++ Standard Library (or stdlib), not Standard C++ Library. –  user744 Feb 25 '11 at 22:28
1  
@Joe, I thought stdlib was the C (not C++) standard library? –  Leif Andersen Jul 31 '11 at 1:39
1  
And to be even more pedantic in C++ you should use cstdlib :p –  Jonathan Connell Oct 1 '11 at 12:27
show 1 more comment

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!

share|improve this answer
    
+1 for the article. I think this answers the question beautifully. –  egarcia Feb 24 '11 at 17:05
8  
My experience is that the more portable your codebase becomes, the more you end up rewriting "standard" components, like STL. –  Jari Komppa Feb 25 '11 at 21:05
add comment

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
share|improve this answer
    
boost::shared_ptr? how so? –  Tili Jul 25 '12 at 16:54
3  
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. –  Kylotan Jul 25 '12 at 17:03
4  
(Worth adding that use of make_shared can alleviate the problem.) –  Kylotan Nov 22 '12 at 18:35
add comment

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.

share|improve this answer
    
True, edited my question to account for this. –  James Feb 24 '11 at 16:33
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
2  
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. –  James Feb 25 '11 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. –  Digital Architect Mar 6 '13 at 7:58
add comment

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.

share|improve this answer
    
There are tools like BCP, y'know. –  Bartek Banachewicz Mar 6 '13 at 15:11
    
Come back to me when you invented a time machine to go back to 2003. Most of the useful bits of boost are in the C++11 standard. BCP still does not beat writing your own, for a number of reasons. Once you have used BCP, it "becomes" your code and you need to maintain it. (rerun BCP?) The resulting code is still more than the hand written one. It is just not worth the hassle to integrate boost into your build system, if the alternative is 2h finger exercise. –  rioki Mar 6 '13 at 15:28
1  
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. –  Bartek Banachewicz Mar 6 '13 at 15:29
2  
@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. –  Digital Architect Mar 6 '13 at 17:16
2  
Sigh Boost also works out of the box, yet still you mentioned maintaining it. I fail to see your logic here. –  Bartek Banachewicz Mar 6 '13 at 17:34
show 4 more comments

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.

share|improve this answer
3  
-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. –  Nicol Bolas Jul 25 '12 at 0:29
1  
... 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. –  Sean Middleditch Jul 25 '12 at 5:27
2  
@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. –  Nicol Bolas Jul 25 '12 at 18:51
1  
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. –  Gerald Jan 23 '13 at 17:29
3  
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. –  Gerald Jan 23 '13 at 17:36
show 7 more comments

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.

share|improve this answer
1  
It's fun, but boost is meant for people that want to do sh*t done, instead of reinventing the wheel. –  Bartek Banachewicz Mar 6 '13 at 15:11
2  
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.) –  rioki Mar 6 '13 at 15:15
    
I think your throwing words into my text, I never said games were a special case, I just said that 98 percent of the time you wont need code from a general purpose lib to make a game. I am also not ignorant for suggesting writing your own code for the small parts instead of using a whole lib. It's a matter of preference. –  Haywire Spark Mar 6 '13 at 16:26
    
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. –  Digital Architect Mar 6 '13 at 16:31
    
@Digital Architect Wow, did anyone read my post? I said "usually specific", for those who do not know English very well, that means "most of the time, but not always". –  Haywire Spark Mar 6 '13 at 16:36
show 3 more comments

Not the answer you're looking for? Browse other questions tagged or ask your own question.