Re: [boost] Core libraries should separated from experimentallibraries

Subject: Re: [boost] Core libraries should separated from experimentallibraries
From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2009-11-26 21:43:49

2009/11/26 Christian Schladetsch <christian.schladetsch_at_[hidden]>

> 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