As a game developer, the recipe I like is C++ with classes but I try not to use inheritance/virtual functions unless there is a clear benefit. Instead, common c

As a game developer, the recipe I like is C++ with classes but I try not to use inheritance/virtual functions unless there is a clear benefit. Instead, common code can be grouped into utility classes. For example, the classic "Shape" base class example with "Circle" and "Triangle",etc derived classes could be instead a "Shape" class that held a small list of arcs segments and line segments. Then a "makeCircle", "makeTriangle", "makeRoundRect" function. If you have a few (hundreds) of objects and many types (circles, triangles,etc) then the "classic" example is better. But in the real world, you often have many (millions) of objects and a small fixed number (say, <10) of different types. Knowing that everything is a "Shape" (and not just something that implements its interface) is very powerful, for example you could collapse all your segments into a spatial data structure and not even keep the "shapes" list around anymore. One of the best things you can do is realize just because you have classes, doesn't mean you can't still use plain functions anymore. I hate it when I see classes like "ObjectMunger" with a function "munge()" ... just write the munge function unless there's a good reason to do otherwise. Templates are actually a good feature if you don't get carried away. But too often I see people use templates like FooMuncher<float> fFooMunch; where <float> (or something) is the only type that is ever instantiated. Why bother templatizing something if you're not going to use that flexibility. If you want a double-precision foo in the future, you can always search and replace ;). Look at the EASTL library for a nice alternative to the STL that fixes some of it's warts such as the clumsy allocators.