2009/11/26 Christian Schladetsch <christian.schladetsch@gmail.com>
Coming from a game-dev background I think I have something to add here.
It may be surprising, but traditional game development, rather than being all glamorous and using the latest technology, is quite the opposite. Sure, we use the latest hardware and API's, but those API's are often written in C, or, lately, very conservative C++.
No game middleware that I am aware of uses even STL let alone boost. I worked at EA for a while, and they had their own version of STL called EASTL.
I've worked in the game industry for past ten years, and even if I have a background in the assembler swamp I can't argue today that it's productive. We're using boost libraries everywhere, from shared_ptr, function, bind,algorithms, regex, filesystem,multiindex, etc, etc. These are easy libraries, but we also use a bunch of traits usage, mpl, asio (our main network backend is all asio, who can say it's efficient to write network code without it) and the past few years fusion has become a life-safer. I hate to see that our middle end engine have reinvent the same broken wheels over and over that we need fixing with modern c++, and having trivial tasks solved in an extremely complex and often inefficient way. Still it's one of the few 'giants', with a giant price tag to it.
Again; Why is that? Why is it that the game development community, lauded for being on the bleeding edge, rejects what we would call modern C++? How can we build all this quite obviously complicated software without the latest and greatest methodologies?
It's a mystery, I agree. Because people are working overtime too much I guess. Personally I don't think it's bleeding edge, except from the graphics side which is being pushed by numbers of transistors and the somewhat organized effort of nVidia and Microsoft (on PC, at least).
Thanks for bearing with me to my punchline: the gamedev community only cares about results and deadlines. They don't have time to risk new things until and unless they have become ubiquitous.
As a result the gamedev community has horrible code, at best, and therefor development time isn't exactly short and thirdparty libraries very expensive. I was surprised first time I read about EASTL, it seemed like the only sane effort in years (solving typical gamedev related concerns in a reusable generic way). I truly dislike the game industry's general approach to software development, it's inefficient, expensive, and doesn't lead anywhere. Whenever we integrate a new third party library we need to wrap it to become usable. How many IFile have I wrapped in my life, just because companies can't read up on how to implement streambuf? They save time but waste mine. Their pricetag reflects the amount of work as well, since everything is nicely 'handcrafted' (i.e. expensive and likely buggy).
Boost has suffered from the opposite of the game-dev scenario: rather than being too conservative, boost has been too liberal and academic. Where gamedev eschews fancy meta-programming for a basic bison or ANTLR script or fast and accurate and specific solutions, and while it does actually care for cross-platform support[1], boost is necessarily confined to the pure C++ model and genericity.
You can never be too liberal. The more techniques added to the mix the
greater chance of finding ones typical problem already solved, and one can move on improving things instead. I think every game company out there, after having put their product out on the shelf, feels like: "ah, finally, this mess is out the door. Now let's start the next one from scratch and this time do it 'right'. " Except maybe for companies who need to maintain their code because they iterate their product titles over the years. Like EA, who probably figured they needed something like STL but with some additional requirements (they mostly reworked the allocators, I think?). My 2 gamedev cents, Christian