a = func(b,c)

In any large C project I’ve seen func() will call f(), g(), h(), m() which in turn call F(), G(), L(), Q(). Now Q() locks a mutex. L() opens a file for logging. G() uses a linked list structure written by some co-op two years ago that is not thread safe (but has worked fine till today). F() uses some obscure macros and has security issues due to the use of strncpy or sprintf.

Now, what is the cost of func(b, c)?

C++ is far for perfect. In fact it is terrible just like C. But it has some solutions for some of the issues in C. It allows OOP (which a lot of C programs end up emulating in awkward ways). It has good robust libraries (stl, boost) and it interfaces in a nicer way to existing object oriented frameworks. It is fast.

A lot of people hate C++ and usually pick up on some esoteric feature. A lot of people don’t get it. A lot of C programmers forget how long it took them to get C. Programming is hard. Life is hard and then you die.

Quoting you: “It’s not about C++ being ‘easy’. I write code in assembly, Python, Haskell, Erlang,… so I think I can deal with ‘not easy’. It’s about the horrible cost creating a mental model of your program creates.”

I have a feeling that you are then dealing with improperly trained programmers. Nobody serious in the industry has problems with a complicated mental model. Complicated != crap, complicated = complicated. And you can argue about writing in language X that are “complicated” all you want.

These languages however ARE designed to be extremely high abstraction layers that take away the cost of dealing with the hardware where you have to. And at the high level, properly done C++ puts to shame everybody right now.

As for the rest, as a contributor to very well known compilers out there, I know what I am talking about. Using C++ has more to do with multilevel access than anything else. Speed is a welcomed side – effect when done right, but then again, you have to actually know how to program in C++, which takes several years to master. It is not your “for dummies” language. It is meant to be used where the others fail and that should kind of suggest of why you don’t have a worthy successor yet.

This is not a contest of “look I can write code in a turing tarpit, does that make me look smart?”. So far, you have no reak immediate alternative to C++ despite the best of intentions. When I will be having a language that supports a system similar to templates and what actually can be done with it, we will talk about it. So far, Haskell’s “Template Haskell” has proved to be worthless. But guess what … it tries to do what C++ does!

Use what you have to, when you have to.

Just my 2c.

And I don’t think AAA games are abandoning C++ within the next 5 years. We might – possibly – see VMs making inroads for scripting purposes, but even that is doubtful given the inertia of our industry.

Thankfully, here I can take a more exploratory stance. And by simply posting my (moderate, I think) objections to C++ and having a fantastic follow-up discussion, I get to clarify my thoughts looking for the elusive ‘better choice’

Middleware could certainly be dealt with via C++ ABI compatibility/FFI. Tools are an issue – the only languages that can compete on a tools level right now are C# and Java. As I said, my hope is on LLVM changing this.

Doing this experiment would be tempting. Just need to find the time… In case it does happen, it would in all likelihood be developed in the HLL first, dropping down to the lower level if performance indicates it’s necessary. Probably in a restricted VM, just so I actually feel some pressure to drop down – small games are not exactly performance hogs.

The Löve code-base also might be interesting, since it is (IIRC) written entirely in C.

Anyways unfortunately neither D or C# are really up to the task yet. But yes you can use C. Here in Japan there are still plenty of C shops, however most work on smaller portable games, but I can say that Virtual Fighter 5 was written in C, not C++. That was epic. Because the glue code was C.

In my spare time, I have actually been writting game components in straight C, and it’s trivial to write physics, graphics, IO, network, persistency, etc. in plain C. The real issue is the glue (gameplay) code. Writting glue code in C is crazy, but writting glue code in C++ is about as cumbersome as C is crazy, so I’ve been using Lua (Jit) for glue, which works great when combined with a good memory allocator.

Anyways I’m still keeping my hopes that something simpler and more concise comes around to replace our reliance C++ within the next 5 years!