[Debate]Using the STL in Games

Pages: 12
Apr 4, 2014 at 7:22pm
closed account (N36fSL3A)
To avoid further derailing SatsumaBenji's thread, I've decided to make my own.

Do any of you think I, or any Game/Engine programmer should use the STL in game engines? Personally I don't think I should; I'd rather just roll out my own containers to suit my needs. I've read at countless places that the STL is too slow for embedded systems and consoles.

What is your stance on this?
Apr 4, 2014 at 7:45pm
I'd say use the std:: library liberally. It's most likely much faster than your own code. The standard containers also allow you to specify your own allocator.

Even if you need special constraints, you can define your own containers or inherit. But do remember that the destructors of standard containers are not virtual.

1
2
std::vector<T> *t = new MyContainer<T>;
delete t; // Undefined behaviour according to standard due to non-virtual dtor. 


Apr 4, 2014 at 7:47pm
You should try to use whatever is provided, without reinventing the wheel (whenever possible). In this case, the STL. The STL implementation wouldn't be 'carelessly' implemented as compilers such as VC++ or GCC is used in large scale productions too. So surely it is indeed optimised (atleast to some extent). There is like a 70% chance usually that it'll be better than some container(s) that you can create.
Last edited on Apr 4, 2014 at 7:47pm
Apr 4, 2014 at 7:49pm
closed account (N36fSL3A)
Of course I'm not worried about a PC version of my engine, but if I ever decide to port it to a different platform (like Android or iOS), then I don't want to have to redesign my engine because the devices I'm targeting weren't made for extensive STL use. I also would have to worry about executable size, phones/tablets have limited memory.
Apr 4, 2014 at 7:56pm
I used to have a personal stl-like system in my games.
Then I used STL, and found out no visible differences.
I also use a std::map<vector2D,tilemap>/ish system to store my 2D world map, seen from a top-down view.
Apr 4, 2014 at 7:59pm
closed account (N36fSL3A)
But have you ported your code to an embedded system?
Apr 4, 2014 at 8:28pm
Both Far Cry 2 and Crysis uses STL. Alt least on PC, but I do ot think that they will rewrite half of the game just for consoles.
Apr 4, 2014 at 8:37pm
I have never used the STL in C++, I have always used the C++ Standard Library. I don't even know where you can get the source to the original STL. Parts of the original STL were incorporated into the C++ standard library, just as parts of Boost are being incorporated into the C++ standard library now.
Apr 4, 2014 at 9:29pm
closed account (N36fSL3A)
Both Far Cry 2 and Crysis uses STL. Alt least on PC, but I do ot think that they will rewrite half of the game just for consoles.
I'm sure they rewrite large portions to make the game able to run at a playable framerate on the relatively low specs of the consoles.

Cry Engine 2 (The engine Crysis uses) is also notorious for the engine not being optimized.
Last edited on Apr 4, 2014 at 9:31pm
Apr 4, 2014 at 9:43pm
LB wrote:
I don't even know where you can get the source to the original STL

It's available on their website, of course: https://www.sgi.com/tech/stl/download.html
Apr 4, 2014 at 9:47pm
Since we are on the topic on game engines thought I would point out.

I can say that Epic doesn't seem to use the STL at all in Unreal Engine 4 as far as I can tell from their source and provides custom implementations instead.
Last edited on Apr 4, 2014 at 9:47pm
Apr 4, 2014 at 10:31pm
Working on real-time systems, I avoid the STL. Actually, it's not just the STL, it's dynamic memory allocation in general. It's an expensive operation.

If I'm using a vector where memory is allocated during initialization, and simply accessed or written to during the real-time process, then it's fine. However, once people start using STL, it's so useful that they like to use them as local variables, and that means that we're allocating the memory over and over during the real-time processing and that's a waste. It's better to just allocate during the initialization phase, or even better: during compilation (using C strings/arrays).

If dynamic memory is REALLY needed during a real-time loop, then you have an unstable system which could take more memory than it releases on average. That's a leak!

In general, containers are optimized for their usage, you have quick allocation and slow access... Slow allocation and quick access. Guaranteed thread-safety at the expense of performance, sometimes you don't care about thread safety and need the performance. Some utilize exceptions for nicer flow with a performance hit, some avoid exceptions to avoid that performance hit. There are many combos that the STL doesn't account for. If it did, it'd be so large that it wouldn't be useful. Use what's appropriate.
Last edited on Apr 4, 2014 at 10:41pm
Apr 4, 2014 at 10:43pm
Only three things in STL use dynamic memory allocation: stable_sort, stable_partition, and inplace_merge (we had to rewrite them for that reason)
The rest allocates from where the programmer instructs.
Apr 4, 2014 at 11:06pm
I think Stewbound killed this debate with his very last sentence. I doubt there is any reasonable argument to rebuke that statement.
Apr 5, 2014 at 1:27am
But the debate is over whether or not the STL is appropriate for game engines. That's like having a debate over what suit looks best on me, then drawing the conclusion that I should just wear whatever looks best.
Apr 5, 2014 at 7:39am
@ Lachlan Easton

Use what's appropriate.

I think Stewbond meant it like this: For PC games/engines use STL since resources aren't so limited. However, for embedded systems like consoles, use your own optimised implementation since resources are limited. That's what he means by 'appropriate'. :)
Last edited on Apr 5, 2014 at 7:40am
Apr 5, 2014 at 8:44am
Well that makes too much sense
Apr 5, 2014 at 9:21am

then I don't want to have to redesign my engine because the devices I'm targeting weren't made for extensive STL use. I also would have to worry about executable size, phones/tablets have limited memory.


Well, I would look at it this way - if I used STL, then I'm a winner - I don't have to spend time reinventing the wheel. But if I can't use STL for some reasons - then it's a tie - I have to write the code, but simply changing the headers/typedefs, and I'm good to go.
If I end up having to write replacements - it's okay. But if I don't - I don't waste my time.
And yes, use what's appropriate. If one feels like STL doesn't fit - replace it. Not much of a dilemma.
Apr 5, 2014 at 9:57am
Lachlan Easton wrote:

Well that makes too much sense

It indeed does.
Apr 5, 2014 at 2:06pm
closed account (N36fSL3A)
Yes, but you might as well avoid the STL altogether if you plan on porting to other systems with limited memory constraints to easy porting.
Last edited on Apr 5, 2014 at 2:06pm
Pages: 12