Quote:Original post by Anonymous Poster
Jesus Christ...I am truly amazed with the things I see posted on this forum.
Christopher is, and I quote from his site, Director of Tools and Technology for internal development at Sony Computer Entertainment America in Santa Monica, and you people are...who exactly? Someone called phantom, another called funny... Learn to show some respect to the TRUE professionals of the industry that you claim to support and STOP BEING ELITISTS.
This is commonly referred to as the fallacy of authority. That is, somebody's being an authority doesn't make them right, although it certainly indicates that such might be more likely. In any case, people are pointing out a number of valid contradictions to the assertion that STL/boost are useless on consoles, so citing authority isn't going to cut it as a rebuttal. And yes, some of us might just be professionals as well.
In any case, I think the first question that has to be asked is WHAT PARTS of STL/boost are in question? It's not like they are all or nothing propositions--you can choose to use as much or as little of them as you want. Are we talking iostreams? In my opinion (just mine mind you) those barely even cut it for PC games, let alone consoles... Perhaps collection classes? Well, that depends on the collection. std::vector, for example, tends to have extremely deterministic behavior--much moreso than, say std::map (which again shouldn't really be used much in PC games either). As far as boost goes, some of its classes are specifically designed to PROMOTE deterministic memory behavior. Memory pools anyone? On the other hand, I certainly wouldn't try to do any sophistocated template metaprogramming (boost::mpl) in a console game (but again that pretty much applies to PC games as well IMO). And on top of all that there's the potential, as has been mentioned by other posters, to write custom allocator classes to get complete control over memory usage.
To put it bluntly, there are a good number of reasons that a categorical rejection of standard libraries as being universally useless on consoles is, shall we say, somewhat misinformed. I haven't done any console programming per se, but I have used such techniques in other embedded systems programming (often on even tighter memory and processor budgets) quite successfully. It's just a matter of putting in a bit of time and effort to learn the inner workings of the library in question (not difficult because source is obviously available) so you KNOW what's going on. Even then if you don't like it, you can always change the parts that don't do what you want rather than reinventing the wheel.
But please, appeals to so called "authority" will not avail you without meaningful argumentation to back them up...
EDIT: I think the original poster hit the nail on the head anyway. It's not so much a matter of template libraries being ill suited to consoles, it's a matter of compilers for consoles--at least those I've seen--being incredibly ill suited to template libraries. They just don't tend to be anywhere near as sophistocated as their desktop brethren.