I'm curious as to why C++ is so popular for games development, and not other languages instead. I know you can create very fast code with it, but what exactly is it that makes it popular?
Is it just because it's fast? Is it some other feature in the language, like the OO paradigm or the portability? Is it because of all the libraries that have been created over time? Or some combination of all these (and other) reasons?
If someone could fill me in on this, I'd be very happy. :-)
Numerous reasons:
There are a few reasons, that I'd like to mention in addition to what @Graham brought up.
low-level language; but a high-level assembler, IMO.
\$\endgroup\$
Raw speed is the primary reason, but actually it's not an either-or decision so lots of game companies are starting to use other languages for parts of the game. Certain tasks require the computer to work as fast as possible (eg. core rendering routines) but many tasks in gameplay code don't have to run all that fast (eg. making the door open when the player clicks on it) which means it is smart to use a much simpler (and thus faster to write programs in) language for those parts. That is why many game engines are written in C++ but embed a scripting language like Lua for writing gameplay code.
The tricky thing to understand is that when choosing programming languages there is an overall tradeoff between efficiency for the computer and efficiency for the programmer. That is, which is more important to you, how quickly the computer runs the code or how quickly the programmer writes the code?
In C++ you can allocate local variables that disappear after the function ends. Usually, these are allocated on a stack.
The stack variables do not contribute to the dynamic memory allocation issues of fragmentation and overhead. Allocating room on the stack is quick and easy (just adjusting a pointer). Dynamic memory allocation usually involves searching a container for an adequate block of memory, marking the memory, then tagging it as occupied. Deallocation involves adding the memory block to a container, and possibly merging it with existing blocks. A lot more overhead than just changing a pointer.
Java and C# allocate memory dynamically, except for primitive types. These languages depend on a run-time environment that will mark a variable to delete, then run a garbage collector at random (unscheduled) intervals to reclaim the memory. In general, the programmer has no control as to when the variable will be tagged for deletion nor when it will be reclaimed (reclamation of used memory is an advanced topic that most C++ and Java programmers don't experience).
The speed of C++ is primarily due to its direct translation to executable code. Java and C# are compiled to an intermediate code which is then interpreted by a virtual machine. In general, interpretive languages are slower performers than directly translated languages.
structs. More to the point, the extremely extremely small increase in speed this nets you is not nearly enough to justify one language over the other. The real reason is stated by @Graham Perks: it's what game developers are expected to know, so it's what new game developers learn, and what new SDKs are targeted for. There are plenty of languages (ex. Go) which are just as fast or faster, and not nearly as inconvenient to write for.
\$\endgroup\$
Commented
Apr 13, 2011 at 22:20
Games were once written in machine language, because they had exotic hardware for which there was no compiler. The hardware also lacked features that C programmers take for granted, such as efficient 16-bit integer math.
Once games settled on familiar hardware, C compilers became available and in a short time all games were written in C.
C++ seemed like a good idea at one time, and most games are C++ today, but engineers are now mumbling about a return to C, and that might actually happen. I would love to work on a game in C, and so would many coworkers. There's no feature new to C++ that I think improves games.
It would seem now that computers are 1000x faster than a few years ago, a high level language would reduce development time ($) making C obsolete.
This has not happened because game buyers know that the hardware is 1000x better, and want to trade their dollars for a game that looks and sounds 1000x better. This removes the slack from the system that a high level language would consume.
Performance requirements in games are brutal. A new frame of graphics must be rendered in under 33ms (or 16ms!) without fail. Everything the hardware does must be accounted for, so that this budget can be met. Any language that goes off and does something with the hardware that the programmer doesn't understand or expect is going to make it very hard to meet this budget. This is an automatic minus against anything high-level.
Game programmers not only work in a low-level language, but they shun high-level data structures and algorithms too. Games typically don't have linked lists and seldom have trees. There is a movement towards avoiding pointers whenever possible*. Any algorithm with more than O(N) time or O(1) space tends not to find wide use.
*If a pointer doesn't cause a cache miss, then why spend 32 bits to store it? If a pointer does cause a cache miss, best get rid of that cache miss.
human with derivates player and enemy?
\$\endgroup\$
Every programming languages have strengths and weaknesses across a range of factors. Examples of these factors are:
One of the most important factors a game programmer cares about is performance. They want to produce an interactive experience, which means it has to be reactive and able to output as much useful (or interesting) data as possible. You want to know how much health you have at any time and don't want to wait for it. And if you click a button, you expect a gun to fire or your character to jump when you say so. A little lag can interfere with this interactivity so you need performance.
Another important factor is preferring to program in the language of the problem, rather the language of the implementation. A game programmer wants to deal with humans, orcs and race-cars, not memory register ED0. They still want the option of diving into the implementation details if they need performance, but it'd be great if for the most part they can deal on the level of the entities in their game world. They have enough to worry about simulating the game world without having to always care about how a linked list works.
C++ fits these two primary factors very well. You can have the performance benefits of assembly or C code with the expressiveness of objects. To see why this is a natural fit for games, compare with some other language options:
The last point is that some of this is historical and political. Many flame wars have been fought between the different programming languages. C# for example might be just as suitable to games development, but it came after C++. Or people don't like that it's from Microsoft. Some people made the move to C#, some didn't. Some people still program games in BASIC, Pascal, and C. Whatever programmers are comfortable with, they'll stick to. Games programmers have mostly been comfortable with C++, possibly because they grew up with C and C++, and it met their needs. If the computer industry is in a state where Java's performance and uptake satisfies enough people, then maybe Java would be the de facto standard game development language.
Legacy and momentum.
Once upon a time code was written in assembler for ultimate performance. As compute power increased, compiled languages became more viable, and C offered the best compromise between power and productivity, at a very basic level being little more than a macro assembler.
C++ was just the natural successor to C. You throw away no former code or knowledge, yet have the potential to expand into new methodologies. C++ is ultimately very flexible, and I've yet to see a design paradigm that can't be at least simulated in C++, whilst being able to maintain near total control over performance.
If you're developing for the consoles, you have no choice: the professional SDKs only come in C++ flavors. Usually they also have C access to most things.
Because many developers are Consoles + PC, it makes sense to do all their PC work in the same language and directly share tech.
Because that's where the pro industry lives, and most everyone wants to be a part of that, most game programmers are C++ programmers.
Because all of that happens, most engine developers are C++ developers too, so when evaluating professional grade engines almost all your choices will be C++.
It's all a big self sustaining engine. Disrupting it would require more than just technical advancement.
FWIW: C# is gaining in popularity for game development. See Miguel de Icaza's blog post. Very interesting read, IMHO.
Although I'm fairly heavily anti-C, C & C++, the one thing they DO have that few other languages have is complete control over the platform it's running on, you can be sure exactly what will be going on at all times, no GC, no glitches.
This isn't as important these days, but it can be for underpowered platforms.
On PC/Mac/Linux it's probably the least portable language you'll encounter these days, and the speed bonus is no longer that much of a difference--Minecraft (Java) is smooth and works on pretty minimal platforms (and any OS) with a single executable--I've yet to see a low-manpower indi C/C++ app with as much functionality and as few bugs, let alone work on three platforms.
So at this point I'd say that most of it is inertia and the conception that real games are always done in C/C++, although the ability to "port" to iPhone and consoles is significant (Even though I'm fairly sure most of the UI of games take a LOT of effort to port except between Windows and XBox).
