The Myth About STL
Author
Can anybody clear a myth that surrounds me about STL. Is STL fast enough for games ??
I know I might get kicked for asking this question given the debate that surrounds the usage of STL. But I have looked around and into a lot of open source engines. Most dont use STL. Can anybody explain that ??
There are certain problems with the Standard Library. If and when those problems become actual, pressing problems for you (they probably won't), you'll know, and you'll know what to do about them. Until that happens, you don't need to worry. Seriously. If you have pressing, unmasterable curiosity about it, though, google EASTL.
It's not the STL anymore, that's an old library most of which was adopted into the C++ Standard Library (SC++L) and this is what we use today.
The SC++L is a part of the C++ specification. Asking whether it's fast enough games is like asking whether for-loops are fast enough games, and the answer is the same: Most of the time, yes.
As a person who isn't sure about whether they're fast enough in the first place and possibly considering rolling their own, it's always worth considering the hyperthetical situation of finding out they are slow. For example, would you actually know how to write a faster for-loop/SC++L than the one provided by the language itself and incrementally optimised over the decades by the experts? Sometimes you just have to accept speed limitations for what they are... limiting.
The SC++L is a part of the C++ specification. Asking whether it's fast enough games is like asking whether for-loops are fast enough games, and the answer is the same: Most of the time, yes.
As a person who isn't sure about whether they're fast enough in the first place and possibly considering rolling their own, it's always worth considering the hyperthetical situation of finding out they are slow. For example, would you actually know how to write a faster for-loop/SC++L than the one provided by the language itself and incrementally optimised over the decades by the experts? Sometimes you just have to accept speed limitations for what they are... limiting.
Quote:Original post by obhi
But I have looked around and into a lot of open source engines.
Such as?
First one that comes to mind: Ogre. Makes abundant use of the SC++L. Discussion of involving boost is going on.
Author
Quote:Original post by dmatter
Asking whether it's fast enough games is like asking whether for-loops are fast enough games, and the answer is the same: Most of the time, yes.
As someone who isn't sure about whether they're fast enough in the first place it's always worth considering the hyperthetical situation of finding out they are slow. Would you actually know how to write a faster for-loop/SC++L? Sometimes you just have to accept speed limitations for what they are... limiting.
I strongly disagree. SC++L objects donot translate to simple looping instructions so the comparison is irrelevant.
On a second thought if you mean that SC++L implements every possible algorithm (which seems impossible) or at least the most optimum codes for container management then it eventually will contain the most optimum code for every container. That might be a good motivation for using SC++L instead.
Author
Quote:Original post by nullsquaredQuote:Original post by obhi
But I have looked around and into a lot of open source engines.
Such as?
First one that comes to mind: Ogre. Makes abundant use of the SC++L. Discussion of involving boost is going on.
CrystalSpace. Irrlitch. Ogre does use SC++L and that is why I said most.
Crystal Space is an ancient piece of shit, and there's some evidence that Irrlicht was written by people who didn't know what they were doing at all.
Quote:Original post by obhiThat's not what I meant.
I strongly disagree. SC++L objects donot translate to simple looping instructions so the comparison is irrelevant.
The SC++L is an actual part of the C++ language; for-loops are a part of the C++ language. Why does it make sense to pick on the SC++L? Why not pick on for-loops? Both of them have implementations, both of them could be reimplemented by a user concerned about speed.
Another way to look at it is, why pick on C++'s standard library? Nobody ever starts these discussions asking about whether C#'s or Java's collection frameworks are fast enough for games.
Quote:On a second thought if you mean that SC++L implements <...> the most optimum codes for container management then it eventually will contain the most optimum code for every container. That might be a good motivation for using SC++L instead.That's somewhat true. If you took the specification of a std::vector for example, it's increasingly difficult to imagine a (portable) implementation that can be any more optimal than the popular implememtations around today. The only way to do better is to change the specification and allow domain knowledge in, this in effect is how the EASTL works (although there are improvements in that which don't compromise the generality).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
