My basic feeling is that C++ tries to do a lot of things and doesn't do any of
them particularly well.  There are so many tricks and traps to C++ that it's
difficult to be proficient without knowing a lot of idiomatic stuff.  And there
are so many traps...

Is C++ better at systems-level bitslapping stuff?  No better than C, certainly.
And C style and linkage being something of the "lingua franca" of systems
programming, why not use C instead of C++ for the really low-level routines?
Games programming in general *does* do a lot of bit-twiddling, but C can handle
that as well as C++, and most higher-level languages support calling C
functions.

Ah, say the knowledgeable ones.  But C++ is "object-oriented", which is good for
large-scale program development.  However, C++ has real problems with its OOP.
Ian Joyner wrote a great paper on this (and expanded it into a book) comparing
C++ to Java and Eiffel; C++ lost on all counts.  If I was going to do an OO
design and implementation, I would use Eiffel for the main body and drop to
straight C for low-level implementation details (this is what I am doing with
PalmOS programming right now, and it is a great combination).  However, neither
one handles stateless programming well, and neither has higher-order functions
(although Eiffel has something like them in the works... not perfect, but
something).  Games lend themselves to OO designs, so a good implementation of OO
is a boon.

C++ does not inherently have good memory management--you have to do all
allocation/deallocation manually.  It didn't take much time with
garbage-collected languages for me to see that GC is FAR superior for at least
90% of applications programming, and games in particular use a lot of
allocation/deallocation.

C++ does not have higher-order functions, which means that you spend a lot of
time rewriting pieces of code you should be able to combine.  For example, in a
series of programs for the PSP, I wrote list classes which could calculate their
mean, standard deviation, etc.  In each calculation, I had to manually iterate
over the lists of numbers, either with numerical indices or iterator objects.
When I tried rewriting a few of these algorithms using Haskell, OCaml, Emacs
lisp, and Scheme, I could get the same effect with fold-right or map, and just a
few lines of code.  The difference is significant.

C++ does not lend itself to dynamic programming.  While this can certainly be
done, it cannot be done as easily as, say, Scheme.  There's a reason that Lisp
got a name for itself as a tool for AI development... in game terms, being able
to load up a game world and have each object own its own set of behavior
routines would be a huge benefit and allow you to add a great deal of
flexibility after the main executable has been released.

I guess after using C++ for several years and then discovering languages like
Eiffel, OCaml, and Scheme/Lisp (yes, an eclectic education, or lack of same), I
just see no reason to use C++ *except* for the industry support it has.  And I
also admit that "industry support" can be pretty compelling.

The disadvantage is simply this: to write OCaml code which executes on another
platform, you have to implement either a bytecode interpreter or a native
compiler back-end, and that would probably be a lot of work.  A compiler which
outputs ANSI C instead of native code probably generates less efficient code,
but you can then use a C compiler as the backend, which seems to be easier.  I
haven't looked too closely at MLTon, which does at least some of this
(outputting ANSI C).