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. :-)

migrated from stackoverflow.com Apr 13 '11 at 15:23

This question came from our site for professional and enthusiast programmers.

  • 7
    Speed is reason enough for me, especially since everyones' complaints about the language don't really make sense to me. – Benjamin Lindley Apr 13 '11 at 14:34
  • A quick guess: Most games are written for Windows. C and C++ languages have been heavily supported by Microsoft. And Finally C++ is preferred because of OOP and template metaprogramming. – sad_man Apr 13 '11 at 14:36
  • @ Matt Thanks, didn't know it existed. Can I move the topic there, or should I delete this one and recreate it over there? – Rainbird Apr 13 '11 at 14:36
  • This has already been asked several times. – Zan Lynx Apr 13 '11 at 14:36
  • 1
    @Benjamin: Then I daresay you haven't written enough in C++, or you've never used a more expressive language like Python (or even C# with LINQ). However, even if for some crazy reason you prefer writing 20 lines code for what many other languages can do in 1, C++'s extremely poor grammar means that programs take significantly longer to compile than they should, and proper IDE tools (refactoring, etc.) are more difficult, if not impossible, to create. – BlueRaja - Danny Pflughoeft Apr 13 '11 at 22:38

10 Answers 10

Numerous reasons:

  • Big one you missed: It's portable, simplifying ports your game engine to iOS, XBOX, PS3, whatever
  • It's fast
  • All the SDKs support it natively
  • Lots of libraries available
  • Everyone writing games knows it, so it's easy to hire experienced games devs for your team
  • It's trivial to embed a game engine scripting language like Lua
  • Alright, thanks for your answers everyone, you've covered everything I needed I think. :-) – KasMA1990 Apr 13 '11 at 19:30

There are a few reasons, that I'd like to mention in addition to what @Graham brought up.

  • Legacy Code - many studios have lots of C++ code, goes to your mention of libraries.
  • C++ is really a high-level assembler, and has direct access to hardware (as direct as you can get running on top of an Operating System at least) and is quite fast. If you want, in C++ you can drop directly down into assembly language for instruction level control (not that it is always wise, its just not possible with Java, C#, Python, etc)
  • DirectX and OpenGL natively support C++, most other languages have "bindings" to the underlying libraries through intermediate layers, thats not to say they aren't fast or can't do many of the same things, but it adds a layer of software between your game and the hardware.
  • As @Graham mentions, lots of programmers know it, so its easy to find experienced developers, and its also quite portable, compared to C# which is stuck on the .NET Framework (there is Mono, but it generally laggs a generation behind Microsoft's implementation.)
  • Don't you mean low-level? – jhocking Apr 13 '11 at 16:25
  • 5
    C++ is a low-level language; but a high-level assembler, IMO. – Nate Apr 13 '11 at 16:39
  • 3
    I disagree. C++ is a high-level language, with the build-in facility to fall back on C (which is a low-level language). – foo Apr 13 '11 at 20:02
  • 7
    C++ is a high level language, as is C. Assembly is low level. Now, C++ is higher level than C is, just as C# is higher than C++ and Ruby/Python are higher than C#. – A.A. Grapsas Apr 13 '11 at 21:18
  • 4
    Why should legacy code be deprecated (not depreciated)? "Legacy code" just means it's old, not that it's bad. – user744 Apr 14 '11 at 7:12

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.

  • 1
    -1 (if I could) - local primitives are allocated on the stack in both Java and C#, and in C# you can create stack-allocated 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. – BlueRaja - Danny Pflughoeft Apr 13 '11 at 22:20
  • C++ is not very good at stack allocation; in fact, it's very hard to allocate STL-compatible objects on the stack. e.g. The last large engine I worked on was in C, and we had a string which you could start on the stack at some fixed size (usually 1K). If it grew past that it transparently moved to the heap. You can do some similar things with std::string custom allocators in C++, but the code is so much trickier to get right. – user744 Apr 13 '11 at 23:18
  • 1
    @Joe Wreschnig: C++ is excellent at stack allocation, just dump an assembly language listing. However, most compiler vendors do not allocate a huge amount of memory to the stack. A common understanding of experienced C++ programmers is that Huge objects are dynamically allocated (heap) not local storage (stack). Huge objects on the stack may overrun into the heap on some platforms as the stack and heap grow towards each other. – Thomas Matthews Apr 13 '11 at 23:31
  • 1
    A common understanding of more experienced C++ programmers, particularly those on game consoles, is that everything that won't overflow the stack is stack allocated or preallocated. C makes this easy because the allocator is not part of the object's structural type. This also makes it possible to free something incorrectly, but in my experience that is a rare problem compared to someone screwing up stdlib-compatible allocator implementations/compatibility. There are also some tricks with placement new, but again, that's more complicated than the equivalent in C. – user744 Apr 13 '11 at 23:38
  • 2
    No. The speed benefit of C++ is due to its ability to use your own custom-written memory manager for heap allocations. Every sane language allocates locals on stack. – Nevermind Apr 14 '11 at 7:54

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.

  • 1
    "There's no feature new to C++ that I think improves games." LOL? OOP? A class human with derivates player and enemy? – orlp Apr 13 '11 at 23:10
  • 2
    @nightcracker: Basic is-a inheritance works fine in C; the relationship you describe is better implemented using has-a for performance and cleanliness reasons anyway. – user744 Apr 13 '11 at 23:14
  • 3
    There is a growing consensus that C++'s OOP features are not appropriate for games, because these features operate on assumptions that are hostile to cache performance. – bmcnett Apr 13 '11 at 23:43
  • Even if you believe that C++ offers no advantages over C you should surely recognize that a return to C offers no advantages over C++ either. – Dan Olson Apr 15 '11 at 19:08
  • @Dan A return to C offers the advantage that "best practices" like not using templates or OOP are enforced by compile-time errors rather than chasing junior programmers around with a stick. Also since the language is simpler presumably compiler and debugger maintenance is cheaper, too. – bmcnett Apr 18 '11 at 17:37

Every programming languages have strengths and weaknesses across a range of factors. Examples of these factors are:

  • Speed on a particular platform
  • Memory usage on a particular platform
  • What functionality it exposes more readily
  • What platforms it exists on
  • What considerations a programmer has to take on-board

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:

  • Assembly: This is raw power. What you write is basically what the CPU does. But at every stage you need to know what is going on with registers and the effect of this, and it never looks like the entities in your game world. The programmer has to make the mental correspondence of what their code does versus what happens in the game. This can be quite a mental overhead.
  • C: Here we have good performance, but we can leverage the experience of gurus to get standard things done (like allocate memory, operate on strings and use standard mathematical functions). We get closer to expressiveness here, but the language more or less forces you to focus on the implementation because you can really only operate on normal data types. Everything is really a char, an int or the like. structs, pointers and arrays can hold things together, but still have to think about the internals.
  • Java: We leapfrog over C++ and get to Java. Java pushes further away from implementation details. In fact, much of the time you don't get access to the lower levels. Java abstracts away much of the implementation details (eg. what CPU or OS you're using) for the reason that it wants to be cross-platform. You can't access the details because they are not there. You don't program for the computer, you program for the platform (the Java platform, which happens to exist on most computers). Moreover, Java has an arguably better language for dealing in the language of the problem than C++. The trade-off is you can't optimize for a particular computer. Whether this makes a practical difference or not comes down to the specifics of the program and the computer.
  • Game scripting language: By this I mean something like UnrealScript, or custom scripting languages strapped onto a game engine. In these you have no access to the underlying engine. You delegate performance considerations to the engine, leaving yourself free to worry about making a game. It's easier to write the game, harder to optimize its performance yourself.
  • Haskell (or your favourite obscure language): Any Turing-complete programming language is equivalent to any other. So while you can write any program in any language, you make tradeoffs, some objective, some subjective. A language like Haskell is more focussed on working in a mathematical spirit. The problems it is geared towards are somewhat different the problems faced in games. It doesn't mean it can't or shouldn't be used for games, it's just its not easily suited to it.

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.

  • 2
    As usual, Miguel pushes his favorite (usually marginal) technologies while ignoring the ways in which C# has actually become a big player in the industry, e.g. XNA. – user744 Apr 14 '11 at 7:13

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).

  • 1
    Oh, I dunno about it only being important for "underpowered" platforms. The other way to look at this is that gaming is always at the forefront of performance on any platform: any new power is immediately gobbled up. If we're talking professional game development, then performance is pretty much the primary concern: you don't write Unreal without maximizing every single last cycle the machine has to offer. Every; single; cycle. On every level, from the graphics engine and disk access up to your UI loop. – Chris Subagio Apr 14 '11 at 18:41
  • @Chris: The best way I've found to describe it to non-game programmers is that games are a domain where speed is a competitive advantage. If your word processor starts in 5 seconds where MS Word takes 10, or reflows in 0.1 seconds where Word takes 0.2, that's worthless. But if your game can pump out even 10% more fragments or show even one more detailed character, that can be a huge competitive advantage. – user744 Apr 14 '11 at 18:56
  • Then wouldn't it be silly to ever code in anything but assembly? It would certainly be at least 10% faster. There is a point where you make a call to trade off performance for maintainability and speed of development. Generally that point is C++ these days. It'd be nice if the ability to go cross-platform like Minecraft had more of a weight. – Bill K Apr 14 '11 at 20:33
  • Ah, but it's a fallacy that coding in assembly is faster: current chips are complex enough that it's difficult for a programmer to outperform a compiler consistently. Only in more constrained domains like SPUs on the PS3, inner physics loops and shaders on GPUs are there still clear advantages. C++ is indeed currently the sweet spot, with the caveat that OOP isn't always the best choice: the ongoing Struct of Arrays vs Array of Structs discussion isn't exactly a language discussion, but C++ clearly leads you to AoS naturally; Sometimes... you really just want C. – Chris Subagio Apr 14 '11 at 21:53
  • The step in programmer efficiency between assembler and C/C++ is also an order of magnitude greater than the step in programmer efficiency between C and C++, or C++ and C#/Java. Fred Brooks pointed this out 25 years ago. – user744 Apr 15 '11 at 7:52

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.