Jump to content
  • Advertisement
Sign in to follow this  
obhi

The Myth About STL

This topic is 3363 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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 ??

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by nullsquared
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.


CrystalSpace. Irrlitch. Ogre does use SC++L and that is why I said most.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by obhi
I strongly disagree. SC++L objects donot translate to simple looping instructions so the comparison is irrelevant.
That's not what I meant.
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).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!