

Ask HN: They say no one knows all C++ so what parts do Game Devs need to know? - metacontent

I recently heard the expression: "If you think you know C++ then you don't know C++".
I take that to mean that C++ is sufficiently large and complex that it is not very common for someone to be deeply familiar with all of its facets.
So this made me wonder what parts of C++ are really essential to know to become a solid indie game developer.
Are there any dark corners that a developer would do well to learn?
======
corysama
First, go read "Inside the C++ Object Model" so that you can have a firm grip
on how the compiler implements everything under the hood.

But, you are looking for dark corners full of gold... Here's where to look:

Policy-based design using templates can make generating optimal code for lots
of different situations only slightly harder than hand-writing optimal code
for a specific situation. "Modern C++ Design" is full of examples that take
this to the extreme. Don't go that far. Just figure out why std:sort with a
functor solidly outperforms qsort (or std:sort) with a function pointer. Also:
type traits are tasty when applied sparingly.

Knowing how to override and augment malloc, new, etc... is critical for
instrumentation and segmentation of allocations. In-place new and destructors-
without-delete can be handy occasionally.

STL's algorithms are great, but the containers are often overkill.
binary_search() and insert(lower_bound()) on a sorted array will often beat a
std:set because most common datasets are small enough to fit in cache when
stored in a contiguous array. Similarly, a sorted array of key-value structs
is usually a better idea than a std:map. If you are on the PC, it is possible
to write large amounts of fast, beautiful code using only pre-reserved
std::vectors (rarely needing new or delete). Boost is soft, warm quicksand.

Don't get wrapped up counting instructions. Memory accesses and cache misses
are 20-200X more important. Most algorithm educational materials ignore this.
Data-oriented design trumps OO. Component-based design trumps inheritance --it
leads to better composability and it is easy to get good Data-OD by batch-
processing arrays of uniform-typed components. Most load screens are 90% disk
seeking. Not reading. Not processing. Seeking...

As a systems programmer, I'm a big fan of C++0X. static_assert is my best
friend. I'm loving auto and lambdas. Move semantics are great for libraries,
but if you need it you might be being a bit too liberal with your allocation
patterns. btw: it's easy to make a pre-c++ox

#define staticAssert(x) typedef char[x:1:-1] _assert_type

that you can use anywhere.

Multithreaded design is important. Done well, it can make everything simpler.
I greatly prefer share-nothing + message passing. Semaphores are handy, but
mutexes usually smell bad. If you think you need to call sleep() you are doing
something wrong.

<http://www.codeproject.com/KB/cpp/FastDelegate.aspx> is handy. Just don't
look under the hood. Scary...

Return value optimization is nice. Compiler intrinsic functions (and out-of-
order execution cpus) are slowly making writing assembly unnecessary (reading
assembly is still important). Getting functions to inline away in optimized
builds is nice, but getting debug builds to run fast is nicer. RIAA can be
nice. Dependency injection can be worth it to not depend on globals
(singletons are self-deception). Careful project structure and #include design
can mean a 10x difference in compile times. Short (preferably
instant/continuous) iteration time is the key to quality.

There's a dozen doors for ya. Take your time stepping through each one. Just
be aware that elegance makes it easier to ship, but shipping is the goal. I've
seen big, awesome games full of gross, bloated code. They were horribly
painful to ship, but they shipped like hell and that's why they won.

~~~
deathflute
I like your point of data oriented design. Do you have any suggestions/links
on how I can learn more about it? Thanks.

~~~
corysama
Unfortunately, not much. The first page of google hits are all pretty good,
but short. Also, Mike Acton of Insomniac has ranted about it a couple of
times.

[http://cellperformance.beyond3d.com/articles/2006/04/perform...](http://cellperformance.beyond3d.com/articles/2006/04/performance-
and-good-data-design.html)

[http://cellperformance.beyond3d.com/articles/2009/08/roundup...](http://cellperformance.beyond3d.com/articles/2009/08/roundup-
recent-sketches-on-concurrency-data-design-and-performance.html)

There are a lot of component-design links here:
[http://stackoverflow.com/questions/1901251/component-
based-g...](http://stackoverflow.com/questions/1901251/component-based-game-
engine-design)

I don't know if any of them address batch-processing though...

------
maximilianburke
For game development you can safely avoid dealing with exceptions and RTTI.
You can probably avoid most template magic, too.

Most game developers use C++ as C-with-classes and generally keep the
inheritance and OOP-ness fairly simple.

~~~
_delirium
This is my experience also, _especially_ with indie games. The crazy dark
corners of C++ tend to come out more often in larger teams than at indie-game
studios.

One approach to finding out more details is to pick a specific engine and see
how it uses C++. For example, take Unity3D, and figure out what parts of C++
you'd need to know to use and understand its API (by reading the docs, looking
at example games, trying out a small project, etc.).

------
checoivan
True. So true.

The thing is c++ is a vast massive monster. Most likely whoever deeply worked
on it, knows there's so much stuff left to learn, and so many deep dives, that
whoever claims expertise is likely to be a newbie who hasn't been close enough
to the edge to see what's ahead.

I remember once, spending like a couple full days along with a graphics
researcher, who worked on that stuff full time, trying to get to work some
rendering done with OpenGL on c++ which just didn't behave when compiled in
MSBuild. Only on MSBuild. We found way later the solution from a guy in a
forum, which was hacking the opengl implementation , overriding some macros
,and doing some other obscure thing on the library as well.

Even today we're both baffled at how that dude came up with that hack.

------
Ogre
Virtual methods are widely used, though heavy use of inheritance seems to be
on the decline.

I'm a big fan of const, including const methods, though the places I'm
especially fond of using it are more MMO specific, (probably) not quite as
relevant for a "solid indie game developer".

It's good to know the basics of templates, for things like lists, hashes,
trees, and maybe vectors, matrices, etc. Using stl or boost is probably fine,
though larger developers always seem to invent their own libraries. I think
that's mostly due to historical lack of support on consoles.

Like another poster said, exceptions and RTTI are virtually unknown in game
development due to performance considerations.

------
newobj
Everything except exceptions and RTTI.

STL/boost are debatable.

