Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Some people say it offers more control to developers, but what is it precisely that can be controlled through C++ which can't be controlled using, for example, Java?

share|improve this question

Java runs in a virtual machine, while C++ is run directly on the hardware. What this means is that you have more control over where your memory goes and what is done with it in C++.

Java is a garbage collected language. You do not have direct control over your memory. You can allocate new chunks of memory, but you do not have (fine) control over when it gets deleted. The garbage collector checks every piece of memory you allocated every x frames and determines whether it's garbage or still being used.

For games this can be disastrous. Every few frames some garbage collector comes along to check every single allocation you've made to see if it's still being used? Talk about a slowdown!

Secondly, most of the libraries we use were either written in C or written in C++. I'm talking about Scaleform, Havok physics engine, PhysX, SpeedTree, etc. All professional packages, used extensively in the industry. If another language wants to be king, it better support them.

My personal view is that Java is really nice for desktop applications and apps, but not for games. Java has a lot of nice tools for developers and it can theoretically be run on any platform that has an implementation of the Java Virtual Machine, but I still prefer C++ because I need that control over my memory. Especially when you start working with exotic data structures (red-black tree, doubly linked list, etc.) it helps to keep a good overview of all your memory allocations.

I'm not saying: don't use Java. I'm saying: think about why you're using Java. Minecraft was built in Java, so it is certainly possible to build games in Java. But would it have been a better game, had it been built in C++? Well, it certainly wouldn't have been so cheap to get it running on the big three (Windows, MacOS, Linux), but even so, it encountered lots of platform-specific bugs in its development, bugs that Java couldn't smooth over.

There are tons of C++ frameworks now for beginning programmers. There's really no excuse not to learn it, especially if you want to further your career in the industry.

share|improve this answer
Just a nitpick, but under most operating environments native code runs in a virtual machine. Java runs in a virtual machine inside a virtual machine. – Skyler Saleh Jul 5 '12 at 7:05
@RTS: It is a bit of a stretch to call op -> micro-op translation a virtual machine, if that's what you're getting at. – user744 Jul 5 '12 at 7:43
No, I was talking about the virtual machine that all applications get put into by modern operating systems to allow for safe multitasking. This occurs on OS that run on architectures without micro-ops (RISC). This includes virtual memory, software interrupts, systems for concurrent hardware access, the operating systems scheduler and the handling of the register file. – Skyler Saleh Jul 5 '12 at 11:42
@RTS I'm not sure that task isolation really qualifies as a VM. It's a RM (Real Machine) with some protection built in. There's no obvious instruction abstraction layer between fetch/exec. Compilers and linkers generate relocatable code as a requirement. The CPU provides hardware support for much of this - which removes the "virtual" aspect. – David Lively Aug 6 '12 at 21:57

Short answer: C++ compiles to native code, so performance is up to the developer,not a runtime or VM.

Long answer:

C++ being "faster" has nothing to do with C++. At the moment, it is one of very few languages available that are supported by tools that produce standalone, native code for multiple platforms.

Back in the day, you could use C, C++, BASIC/2, Delphi, etc , and get efficient, freestanding executables. The choice of language was a matter of personal preference and market forces.

These days, the assumption that "C++ is faster" is essentially a self-fulfilling prophecy, though LLVM is in a good position to change that as it makes whatever goes into the parser moot, as it once was.

Borland had it right: Multiple languages that were parsed, first optimizations applied, then passed to a common backend compiler and linker. Which is effectively one of LLVMs major accomplishments.

Java is structured in such a way that it would be very difficult to implement without the JVM. Oddly enough, C#, commonly, and incorrectly, assumed to be roughly equivalent to Java, already compiles to native code on several platforms, including iOS.

Top of my Christmas list? A time machine to go back and add properties, real exception handling and actual WORKING polymorphism to C++, and get rid of the f"d up arrow syntax crap that the parser can figure out on its own. I wrote a preprocessor for that 10 years ago because it's freaking stupid.

share|improve this answer
Do you mean indirect member access (as in h->x)? Removing that would make handle and smart pointer types way less useful. If you argue to change it just for raw pointers, you just made the language less consistent. – Lars Viklund Jul 5 '12 at 5:55
What doesn't work about C++'s polymorphism? – Casey Jul 5 '12 at 14:19
@LarsViklund yes, that's what I mean. But, while the address, dereference and member operators (&,*,::,->...) all have different meanings, most of the time its possible to infer the drsjted result from context. Things could have been simplified up front, as is done in other languages. A minor sticking point, but one that has the potential to increase code complexity (and thus dev time and cost). – David Lively Jul 5 '12 at 14:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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