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?

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.

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.

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.

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.

But have you ported your code to an embedded system?

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

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.

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

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.

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.

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.

I think Stewbound killed this debate with his very last sentence. I doubt there is any reasonable argument to rebuke that statement.

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.

@ 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'. :)

Well that makes too much sense

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.

Lachlan Easton wrote:
Well that makes too much sense

It indeed does.

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.