EASTL and runtime library design

I spent a bunch of time reading through the documentation for EASTL -- the Electronic Arts Standard Template Library. This library is now close to 3 years old, but this is the first I'd heard of it. Of course, I'm somewhat out of touch with the C++ world nowadays; I did most of my C++ programming in the mid-90's, when we were still using Windows 3.1 and the C++ STL was just being created.

Although I no longer work in C++, I still found the overall paper very interesting. I think it's great when somebody takes a really close, detailed, critical look at a large and substantial piece of software, as there is always something to learn. In fact, I think that the best point that the EASTL paper makes is: no matter how good your standard library and your programming infrastructure is, it can always be improved, and it can always benefit from a thorough and detailed critique. There are similar efforts in the Java world which I am familiar with; for example, consider the Google Collections Library, which is a similar attempt to improve on the base JDK collections library.

My favorite part of the EASTL paper was the part where the author itemizes the issues that game programmers encounter, including:

• No matter how powerful any game computer ever gets, it will never have any free memory or CPU cycles.


• Game developers are very concerned about software performance and software development practices.


• Game software often doesn't use conventional synchronous disk IO such as <stdio.h> or <fstream> but uses asynchronous IO.


• Game applications cannot leak memory. If an application leaks even a small amount of memory, it eventually dies.


• Every byte of allocated memory must be accounted for and trackable. This is partly to assist in leak detection but is also to enforce budgeting.


• Game software rarely uses system-provided heaps but uses custom heaps instead. See Appendix item 26.


• A lot of effort is expended in reducing memory fragmentation.


• A lot of effort is expended in creating memory analysis tools and debugging heaps.


• A lot of effort is expended in improving source and data build times.


• Application code and libraries cannot be very slow in debug builds. See Appendix item 9.


• Memory allocation of any type is avoided to the extent possible.


• Operator new overrides (class and global) are the rule and not the exception.


• Use of built-in global operator new is verboten, at least with shareable libraries.


• Any memory a library allocates must be controllable by the user.


• Game software must be savvy to non-default memory alignment requirements.

As I read this list, I was struck by the realization that, really, almost nothing here is specific to game programming. Really, this is just a list of considerations that apply to any software that you care about. This list of concerns is equally important to people writing operating systems, database systems, networking software, etc.

There was a time when people worked really hard on software: slaved over it, deeply considered every line of code, measured and re-measured and tuned every bit of it. This is still important; using great software is just a completely different experience than using sloppy software.

It's nice to see a paper written by some people who obviously care a lot about writing really great software, discussing, in detail, why that's hard to do, and why you really have to constantly focus on every little detail in order to do it.

Even if you aren't a C++ programmer, give the paper a try: I think you'll enjoy it.