Discussion Point: C++ STL & Games - by Geoff Evans

The C++ STL is pervasive in tools development.  C++ STL coupled with memory heaps backed by paging files will take one pretty far.  However, there are some aspects to C++ STL that make sharing code between tools and runtime challenging.

In my mind it would be awesome if there was a container library like C++ STL that supported:

  • Allocator objects as instance API as well as static API
  • Usage of heap handles (instead of pointers) that would allow memory relocation
  • Creating and synchronizing threads in a platform-agnostic way
  • Lockable containers that are safely accessible from more than one thread
  • Sleeping threads on empty containers (with semaphores or events)
  • Basic archiving of data to / from flat files

Here are some solutions I have found:

  • Intel’s Thread Building Blocks address the locking and sleeping issues.
  • EASTL conquers the instance allocator problem, but it is closed source.
  • C++0x could potentially address some of these (with native support for threads) but I would expect that support or C++0x is still years away (especially for game console compilers).

What other solutions are out there?  Are there any resources out there that put all of these pieces together?  It seems to me that a container library that solved these problems in symphony could be very powerful for working with code that needs to work on both workstations and consoles (E.G. portable code that abides by strict memory requirements).

Has anyone solved any of these problems interfacing directly with C++ STL?  If not, does the games industry need something besides STL that could suit these needs better?

4 Responses to “Discussion Point: C++ STL & Games”

  1. rotoglup says:

    Regarding Intel TBB library, is its GPL licence a problem ?

    I crossed a rant on this topic on John Ratcliff blog (http://codesuppository.blogspot.com/2009/01/intels-giant-screw-up-with-intel.html).

    Couldn’t Intel TBB also handle the platform-agnostic threading ? or boost ? I’m involved in tools, but PC only, so I’m not familiar with console-related issues…

    Cheers.

  2. Geoff Evans says:

    Actually we had some thread deadlocking issues with sleeping threads on the concurrent vector class, so we just ended up rolling our own solution with win32 threads and semaphores.

  3. Rui Pires says:

    I do not know how easy(viable) it is to use Boost for console development, but from what (little) I know about it, it covers some of those issues.

    # Creating and synchronizing threads in a platform-agnostic way (also in C++0x)
    # Basic archiving of data to / from flat files

  4. Delisa Parm says:

    This is a outstanding blog post, I found your web page searching aol for a related subject matter and came to this. I couldnt find to much other info on this summary, so it was pleasant to find this one. I probably will be returning to check out some other posts that you have another time.

Leave a Reply