Modern C++ Game Programming Examples

Question

To what extent are modern C++ features like:

1. polymorphism,
2. STL,
3. exception safety/handling,
4. templates with policy-based class design,
5. smart pointers
6. new/delete, placement new/delete

used in game studios? I would be interested to know the names of libraries and the C++ features they use. For example, Orge3D uses all modern C++ features including exceptions and smart pointers. In other words, if I would be looking for an example for a game library using modern C++, I would go to Orge3D. But I don't know if these features deter game studios from using Orge3D.

Further I don't know if there are other examples. For example, I used Box2D some time before briefly, but it uses only placement new, and class keyword as the C++ features. Even encapsulation is broken in these classes as all members are public.

Ideally, if C++ features would be the best match for all situations, these would be used most often. But it seems not. What are the impedances? The obvious one is having to read stacks of books, but that's half a reason only. This question is a follow up on "C++ for Game Programming - Love or Distrust?" (From the responses there I got an impression that many C++ features are still not used in games; which is not necessarily the way it should be).

Answer 1

1. Pretty extensively, although people are mindful of the overhead of virtual function calls
2. It depends. Some developers swear off it completely, others make limited use of containers like vectors that will have good cache coherency and runtime performance and won't allocate constantly. I think a general observation would be that the more console-oriented the studio the less STL they use. PC developers can get away with it because they can fall back on the virtual memory system and there's plenty of CPU. Console guys care about every allocation and if you are doing a multiplatform title you get into the wonderful world of different platform's STL implementations behaving differently and having different bugs, although this situation has certainly improved in recent years. Game developers also like to manage their own heaps and allocations and this can be difficult to deal with with STL.
3. Expect it to be disabled in the compiler settings
4. Haha, good one.
5. I'm not sure. I haven't really seen smart pointer use in game code, although aside from a general aversion to dynamic memory I don't think there's anything particularly objectionable about smart pointers from a game development standpoint.
6. This one again depends. PC guys may allocate and deallocate like they just don't care. Console guys care about every allocation. That doesn't mean no new and delete but it can mean that dynamic allocations are only done once when the game or current level is set up and then left until the game or current level is torn down. Per frame allocating and deallocating is best avoided, not just to keep total memory use down but to avoid fragmentation. You'll see a lot of fixed sized arrays and statically allocated structures in a console game engine.

Answer 2

I've worked in 2 game companies, seen a number of codebases, and observed a number of debates on matters such as these among game developers, so I might be able to offer some observations. The short answer for each point is that it varies highly from studio to studio or even from team to team within the same studio. Long answers enumerated below:

• polymorphism,

Used by some studios but not others. Many teams still prefer to avoid it. Virtual function calls do come at a cost and that cost is noticeable at times even on modern consoles. Of those that do use polymorphism, my cynical assumption is that only a small percentage use it well.

• STL,

Split down the middle, for many of the same reasons as polymorphism. STL is easy to use incorrectly, so many studios choose to avoid it on these grounds. Of those that use it heavily, many people pair it with custom allocators. EA has created EASTL, which addresses many of the issue STL causes in game development.

• exception safety/handling,

Very few studios use exception handling. One of the first recommendations for modern consoles is to turn off both RTTI and exceptions. PC games probably use exceptions to much greater effect, but among console studios exceptions are very frequently shunned. They increase code size, which can be at a premium, and literally are not supported on some relevant platforms.

• templates with policy-based class design,

Policy based design... I haven't come across any of it. Templates are used pretty frequently for things like introspection/reflection and code reuse. Policy based design, when I read Alexandrescu's book, seemed like a flawed promise to me. I doubt it's used very heavily in the game industry, but it will vary highly from studio to studio.

• smart pointers

Smart pointers are embraced by many of the studios that also use polymorphism and STL. Memory management in console games is extremely important, so a lot of people dislike reference counting smart pointers because they're not explicit about when they free... but these are certainly not the only kind of smart pointer. The smart pointer idea in general is still gaining traction. I think it will be much more commonplace in 2-3 years.

• new/delete, placement new/delete

These are used frequently. They are often overridden to use custom allocators underneath, so that memory can be tracked and leaks can be found with ease.

I think I agree with your conclusion. C++ isn't used in game studios to as much of an extent as it could be. There are good and bad reasons for this. The good ones are because of performance implications or memory concerns, the bad ones are because people are stuck in a rut. In a lot of ways it makes sense to do things the way they've always been done, and if that means C with limited C++ then it means C with limited C++. But there are a number of anti-C++ biases floating around... some justified and some not.

Answer 3

1. Lots
2. Way to much. But we are trying to limit ourselves to std::vector at runtime.
3. None what so ever.
4. What?
5. Our code has been infected by this illness yes. We will start whipping people for spreading the scourge however.
6. Yes. Lots.