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?


2 Answers 2


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.

  • 1
    \$\begingroup\$ 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. \$\endgroup\$ Jul 5, 2012 at 7:05
  • 1
    \$\begingroup\$ @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. \$\endgroup\$
    – user744
    Jul 5, 2012 at 7:43
  • \$\begingroup\$ 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. \$\endgroup\$ Jul 5, 2012 at 11:42
  • \$\begingroup\$ @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. \$\endgroup\$
    – 3Dave
    Aug 6, 2012 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.

  • \$\begingroup\$ 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. \$\endgroup\$ Jul 5, 2012 at 5:55
  • 1
    \$\begingroup\$ What doesn't work about C++'s polymorphism? \$\endgroup\$
    – Casey
    Jul 5, 2012 at 14:19
  • \$\begingroup\$ @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). \$\endgroup\$
    – 3Dave
    Jul 5, 2012 at 14:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .