doom3 sdk container library !?!
Author
Just downloaded doom3 sdk and had a quick glance and noticed how nicely things where laid out until i was a little bit shocked to see that they had written there own containers & no use of functors and stuff instead of using STL but there is use of templates, thought it would be something to talk about, i would love to know the rationale behind it (before someone says for efficency you can be just as if not more efficent when done properly).
I can only make wild guesses here.
1) Control. Maybe the developers (it's not just John) love to know exactly what's going on. Everyone who ever tried debugging and acceidently steps into STL functions knows what I mean [wink].
2) Memory fragmentation (mh. well this is not a valid point at all since you can always provide a custom pool-allocator).
3) Lack of experience with using the STL? I mean, no one knows when these components where created and it might have been years ago. Maybe even shortly after id soft made the transition to C++...
*puts flamesuit on*
These are guesses from the top of my head and I might be totally wrong here.
--
Pat.
1) Control. Maybe the developers (it's not just John) love to know exactly what's going on. Everyone who ever tried debugging and acceidently steps into STL functions knows what I mean [wink].
2) Memory fragmentation (mh. well this is not a valid point at all since you can always provide a custom pool-allocator).
3) Lack of experience with using the STL? I mean, no one knows when these components where created and it might have been years ago. Maybe even shortly after id soft made the transition to C++...
*puts flamesuit on*
These are guesses from the top of my head and I might be totally wrong here.
--
Pat.
Quote:Original post by Pipo DeClown
Is the STL available on the XBox?
But of course. Every piece of hardware that has a C++ compiler available, can access the STL. It's part of the standard (hence the name[wink]). You can even use the STL on the GBA (though this is not advisible for various reasons[smile]).
The probably did run into some issues with the STL containers. I ran into the fact that std::vector passes some argument by value somewhere which totally screwed up my SSE classes so I ended up rolling my own. Solid containers with iterators and standard algorithms aren't exactly hard to write.
Author
Quote:Original post by darookie
3) Lack of experience with using the STL? I mean, no one knows when these components where created and it might have been years ago. Maybe even shortly after id soft made the transition to C++...
I think they where created in 1993, introduced into c++ 1994 & became part of the standard library when c++ was standardized in 1998.
Maybe it has something to do with compiler compliance, its only been recently that c++ compilers are more standard compliant & better supported for templates but they use templates anyways (very minimally thou).
Quote:Original post by snk_kid
I think they where created in 1993
I think Darookie meant we didn't know when id's containers were made.
I think it probably makes things easier if all licencees are using the same containers and not relying upon having the same version of the STL installed as id has.
One guess would be portabilty, not all STL's are equal and by "rolling their own" i guess they wouldnt run into problem with a particular port having a non-standard or buggy STL
I guess it is possible that it is partly due to optimization (but the other reasons mentioned sound more plausible). If it is for optimization, I won't argue* with id software, those guys are professional optimizers and know what they're doing :P
*By argue I mean "premature optimization is the root of all evil" kind of remarks.
*By argue I mean "premature optimization is the root of all evil" kind of remarks.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement