This paper came up on programming.reddit today: Electronic Arts Standard Template Library. Abstract:

Gaming platforms and game designs place requirements on game software which differ from requirements of other platforms. Most significantly, game software requires large amounts of memory but has a limited amount to work with. Gaming software is also faced with other limitations such as weaker processor caches, weaker CPUs, and non-default memory alignment requirements. A result of this is that game software needs to be careful with its use of memory and the CPU. The C++ standard library's containers, iterators, and algorithms are potentially useful for a variety of game programming needs. However, weaknesses and omissions of the standard library prevent it from being ideal for high performance game software. Foremost among these weaknesses is the allocator model. An extended and partially redesigned replacement (EASTL) for the C++ standard library was implemented at Electronic Arts in order to resolve these weaknesses in a portable and consistent way. This paper describes game software development issues, perceived weaknesses of the current C++ standard, and the design of EASTL as a partial solution for these weaknesses.

It's a very interesting read.

I caught that too.

I think some of the observations within were based on a particular implementation of the STL, though e.g. the stuff about void-pointers in node-based containers.

But it is an interesting discussion, certainly.

Edd

Quote:Original post by the_edd
I think some of the observations within were based on a particular implementation of the STL, though e.g. the stuff about void-pointers in node-based containers.

Well, that's the point--they wanted unified behavior across different implementations.

Well, they can't demand something like that, IMO, at least not in this way.

Sticking to the standard does give unified behaviour. That's the whole point of the standard. They're talking about implementation details, which the standard does not define and nor should it; it's up to the library implementer to decide what's the best way to do something for a particular system.

If the implementer of the library they're using isn't doing a very good job, they should take it up with them and not impose rules on every implementer. I realise that's not what they're doing.

A lot of their suggestions and comments are rational and well-justified and I agree with a lot of what is said.

But I think in a few of the situations highlighted, the issue seems to be with a particular implementation of the standard library that they're using.

Edd

I understand what you mean--you can't specify, in the standard, that implementations should provide the programmer a proper view of the data with a debugger. That's outside the scope of a language standard. That's why they came up with their own (cross-platform) implementation that guarantees it.

Very interesting read, thanks for posting it.

The document sums up perfectly why we have banned the use of the STL/standard library in all of our corporate projects, and replaced it by our own implementation. On the other hand, it gives some very interesting ideas about optimizing and extending this in-house implementation.

Quote:
Sticking to the standard does give unified behaviour. That's the whole point of the standard.

While this is true, it is also its greatest weakness. As a programmer, I expect a certain amount of functionality and ease of use from a library. This is specifically true for areas such as efficient debugging, efficient and flexible performance and storage characteristics, low memory footprint, highly controllable multithreaded behaviour, cross-DLL boundary safety, etc.

These are all implementation details, and thus ignored by the current standard. Yet, they are immensely important.

Quote:While this is true, it is also its greatest weakness. As a programmer, I expect a certain amount of functionality and ease of use from a library. This is specifically true for areas such as efficient debugging, efficient and flexible performance and storage characteristics, low memory footprint, highly controllable multi-threaded behaviour, cross-DLL boundary safety, etc.
These are all implementation details, and thus ignored by the current standard. Yet, they are immensely important.

Well the standard doesn't mention DLLs or multithreading (yet) at all. It can't mention DLLs because they're tied to a particular platform. One could argue that something related to shared libraries could be added but the differences in the way shared libraries are handled between platforms is so broad that it would be pointless trying to extract vague and tenuous commonality for potential standardisation.

Doing any kind of multi-threading in C++ is dangerous unless you know your compiler and platform inside out (which you may, of course) because the standard behaviour is defined in terms of a single threaded virtual machine (for now) and the guarantees for different platform/compiler combinations vary greatly in the wild.

I guess I'm just saying it's unfair to criticise a platform-neutral standard for failing to standardise something platform specific. I'm not entirely sure that's what you were doing, though :)

If there are other issues with the library, it's often the implementation that needs to be improved and not the specification. For instance, a large number of the suggestions made in the article are only improvements over a particular implementation.

I certainly agree that debug-ability is generally quite bad, though it doesn't need to be. The library being developed for the Open Watcom compiler is very readable, for example.

One of the things that I really agree with is that the whole allocator concept, as it stands currently, is just severely flawed for a number of reasons. I really hope that gets sorted in the standard some time soon.

Edd

It works for them, obviously. But they're also a large enough company to have staff that can be dedicated to development and maintainance. Most of us, unfortunately, don't have that luxury -- most non-publisher entities don't either.

Good for them though, interesting read.

The question is, are they willing to release it under a permissive license? Sadly, I suspect they're not, but a man can dream.