Boost/STL in games?
Author
Do the Boost and STL libraries have a place in console games?
I've been exploring the Boost library (www.boost.org) and find it pretty fascinating, but of the three game companies I've worked for none have ever used even the STL, making it pretty unlikely that Boost will be used - usually the reason is due to poor PS2 compilers that wouldn't support the template specification needed, or problems with the memory taken up by the stl (which seems like a cop out since it is customizable). Has anyone shipped a game on a console using either of these libraries?
It would certainly be nice to not have to learn another dynamic array interface again, thats for sure :) Let alone the myriad of things boost can do.
-John
Quote:Original post by johnnyk
Do the Boost and STL libraries have a place in console games?
I think it's safe to say they're frowned upon because they are over-engineered, have difficult-to-predict memory behaviors, and give obscure compiler errors that do not facilitate easy debugging.
Quote:Original post by Christer Ericson
have difficult-to-predict memory behaviors
Which is why you can write your own allocator for them, plus I'm pretty sure they have well defined charactistics when it comes to memory useage.
Quote:
and give obscure compiler errors that do not facilitate easy debugging.
Thats just a lack of familarity with the error messages templates throw at you, which will big, arent that hard to understand if you apply a bit of brain power to them (infact, often the key to the error is within the first few characters or the last few).
We're using the STL in our Nintendo DS project, and the DS isn't the most powerful machine out there. And we're not even messing around with custom allocators.
It's part of the language, so long as you use it properly there's no problems with it.
It's part of the language, so long as you use it properly there's no problems with it.
Quote:Original post by phantomOn a continuously streaming game like God of War we need 100% deterministic memory behavior; "pretty sure" doesn't cut it.
Which is why you can write your own allocator for them, plus I'm pretty sure they have well defined charactistics when it comes to memory useage.
STL is fine for tools, of course, where we don't have such strict requirements.
I don’t know what "continuously streaming" means, but I am sure you have done some performance analysis of the STL on the PS2. Care to share?
Quote:Original post by Christer EricsonQuote:Original post by phantomOn a continuously streaming game like God of War we need 100% deterministic memory behavior; "pretty sure" doesn't cut it.
Which is why you can write your own allocator for them, plus I'm pretty sure they have well defined charactistics when it comes to memory useage.
STL is fine for tools, of course, where we don't have such strict requirements.
He said "pretty sure" in the context of the default allocator having well defined characteristics -- which is why he suggested custom allocators as an alternative. If you use a custom allocator, you can make the STL containers' memory behavior as predictable as you like. Take a look at Boost.Pool (and pool_alloc in particular), for an example.
jfl.
Quote:Original post by Christer Ericson
On a continuously streaming game like God of War we need 100% deterministic memory behavior; "pretty sure" doesn't cut it.
You have the source, it's easy to figure out how the library implementation you are using does things. It's not like there are trade secrets in there. Now (and please don't take that as a personal attack), that assumes you're able to read code and grok the conventions used.
It's not as if the library relies on rand() to decide whether to allocate more memory for its container or not. And while you're at it, you might decide to modify (*gasp*) your standard library, if you don't like, say, capacity doubling on vector reallocation. But this assumes a level of comfort with the library that I don't expect to find in many places, considering how much balking there seems to be about simply using it.
Quote:STL is fine for tools, of course, where we don't have such strict requirements.
Agreed. That's a context in which there shouldn't be any objection except, as usual, unfamiliarity.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
