Most professional game engines like Unreal, Cryengine etc. uses C++ . Why c++ is the best language for game development. I want to ask the question as i want to be a professional game programmer in future and the answer will motivate me to learn more and more c++ in future. Please tell me is it really a good idea to be a expert in c++ for the sake of getting a job as a game developer. I know java and bit of C# , should i learn c++ in more in depth ? and what engine should i use in future? Currently i think it will be a good idea to use unity, as i'm a beginner. Thanks a lot, i really need your advise.

Most people using C++ does it because they have no choice. C++ is an old beast with tons of cumbersome issues, it's just that there are compilers for every single platform ever, so if you want to support every single platform ever , then your only realistic choice is C++. Most engines etc are written in C++ but incorporate some form of scripting language which can then be used for the creation of the actual games.

I think the main reason is that C++ is low level programing language with OOP supported, because it's such low level you are less restricted, and with less restrictions you have more power to manipulate things... Also very good thing is that you have direct access to computer memory

As stated above, C++ is available for pretty much any platform you write games on. Most importantly, MS's, Sony's, and Nintendo's consoles all support C++ and rarely support anything else. (MS supported a stripped-down version of .NET on the 360 for XNA, but I'm not aware of any other examples)

Also, there is a ton of old legacy code written in C/C++ that would take a lot of time and testing (and more importantly, money) to convert to any other language.

And that's not to mention that pretty much any low-level system library is going to have C API. So even if you're writing in a different language someone somewhere is still going to be dropping down to the C way of calling functions to do things like open a file or draw a pixel on the screen.

Aside from the above reasons, C/C++ has a very strict policy of "you only pay for what you use" which makes it ideal for high-performance and resource-restricted applications. Which is basically what game programming on a console is. Most other languages have hidden costs (most commonly, garbage collection) that you cannot get rid of.

Of course, if you're not doing triple-A development, you may have a lot more freedom to pick your language as you aren't (typically) going to be making something for a console, and you can sometimes afford to trade code efficiency and speed for ease of development. Though I would argue that proper "modern" C++ is about as easy to work with as any "higher level" language except in certain edge cases.

Most modern and higher languages, like Java and C#, are running in a runtime (engine like program). So if there is no runtime for you particular platform, you can't deploy you game/program on that platform. So you are dependent to others.

C++ and C is compiled into machine code, which can be ran without any additional program. Furthermore, as other already stated, you have almost complete freedom to do anything in C++ and C. You can really mess around with pointers and your memory, which often results in very fast code. So the benefit is speed, which is very important in engines and games.

Most modern and higher languages, like Java and C#, are running in a runtime (engine like program). So if there is no runtime for you particular platform, you can't deploy you game/program on that platform. So you are dependent to others.
C++ and C is compiled into machine code, which can be ran without any additional program.

C/C++ are dependent on your platform having a decent compiler.

It's pretty good these days, but on the Wii, PS2, Xbox (original), the C++ compilers were teeerrriiiibbblllle! Any C++ games from that era were likely written in a very strict subset of C++, with a lot of plain C thrown in for good measure

In a game typical critical performance code areas could be resource and memory management. "High level", such managed and interpreted, programming language could potentially negatively impact on that area.

Since in "AAA" games usually every milliseconds matter, it is often reasonable sacrifice the high productivity of certain programming languages for the critical performance portions of the project and if you need to squeeze every possible milliseconds then native programming languages (like C and C++) are the tools you need.

C++ provides low level programming and supports a good range of programming paradigms (compared to C).

This two main "features" made C++ the "best fit" choice for AAA games for critical-performance-code areas and contribute to the continue development of solid and well performance compilers, libraries and frameworks (which are as well additional and strong incentives).

Modern C and C++ are also more portable than most people think, even (and especially) compared to "write once, run anywhere myth" languages.

Most modern and higher languages, like Java and C#, are running in a runtime (engine like program). So if there is no runtime for you particular platform, you can't deploy you game/program on that platform. So you are dependent to others.

MSVCRT says hi. (Hint: check what the acronym means.)

You are always beholden to others, no matter what language you use: MSVCRT, MSCORLIB, libstdc++, liblua - it has to be there otherwise you can't use it.

Historically, games have been very performance sensitive, and few languages really target that demographic. Prior to C++, a lot of people used C. I suspect they jumped to C++ by and large simply because... well... at least it's better than C.

It's still used today largely due to inertia. There are competing languages like Rust and D, but none of them are stable enough that I'd use them for a multimillion dollar project like a game, and none of them have the library/tooling infrastructure in place that C++ does.

It's the most popular because it was the most popular. There are some technical reasons, but this trumps them all. It's cause and effect too... due to it's popularity, tools exist. Tools exist because it is popular. It became the most popular because it was backward compatible with the previous most popular language.

Also, when Game Company X is going to start game Z after finishing Y using C++, what language are they going to use, the one they have workers proficient in and have a large existing code base, or something completely new with arbitrary advantages?

If Java or C# came out and were binary and source compatible with C++, just with modern syntax, type safety, better generics, etc... the industry would have switched ages ago. Well, if they were allowed to that is. Both Java and C# owe their existence to a single master, and that is another advantage ( and disadvantage ) of C++. C++ is run by committee, meaning no corporate lock in, but a glacial development cycle.

Your actually all missing the key point of C++ it was mainly created to deal with larger and larger code bases that's why classes where created, for reusable code and then it evolved into a standardised lanuguage from there.

The compiler strips all your C/C++ into Assembly language first before the code generation stage anyway.

You should really download the GCC source code and have a look through it, you will see that it supports mainly many CPU's.

Your actually all missing the key point of C++ it was mainly created to deal with larger and larger code bases that's why classes where created, for reusable code and then it evolved into a standardised lanuguage from there.

The problem is, C++ is a terrible language for dealing with large codebases.

Its insane compilation model leads to terrible build times, and completely breaks down in large codebases. A windows build of Qt5 takes >2 hours on a quad core system with a SSD. A comparable codebase in C# would take less than 10 minutes (my system manages ~100Kloc of C# per second, which would build the whole 10Mloc of Qt5 in 1.5 minutes.)

Its lack of garbage collection means that long-running applications will suffer from memory fragmentation issues unless special measures are taken.

The lack of an ABI means that its impossible to create reusable components in a truly portable manner.

The complexity of the specification means that no two compilers implement the language in a compatible manner. Portable code is littered with "#ifdef _MSC_VER > 1700" and similar line noise.

C++ may have been an improvement over C when it was created (debatable), but right now the main reason for its popularity is inertia.

Its insane compilation model leads to terrible build times, and completely breaks down in large codebases. A windows build of Qt5 takes >2 hours on a quad core system with a SSD. A comparable codebase in C# would take less than 10 minutes (my system manages ~100Kloc of C# per second, which would build the whole 10Mloc of Qt5 in 1.5 minutes.)

Its lack of garbage collection means that long-running applications will suffer from memory fragmentation issues unless special measures are taken.

The complexity of the specification means that no two compilers implement the language in a compatible manner. Portable code is littered with "#ifdef _MSC_VER > 1700" and similar line noise.

C++ may have been an improvement over C when it was created (debatable), but right now the main reason for its popularity is inertia.

Those are, in many ways, the strengths of the language.

The reason build times are insanely huge is because of the compilation and linking model. Pull everything in. Inline everything you possibly can. Optimize and precompute everything possible, perform every optimization possible, restructure everything from the biggest algorithms to the smallest pigeon-hole to be cache friendly, OOO-core friendly, branch predictor friendly, lookahead table friendly, and more.

Lack of garbage collection means less memory used; it is well established in academia that GC-style systems generally require 1.5x the memory requirements to maintain similar performance. Yes it requires more brain power for the humans to manage the object lifetime, but when you are on a console device or mobile device with memory measured in megabytes taking a 1/3 reduction in effective memory just to use automatic garbage collection is an unwise tradeoff.

The ability to have system-specific improvements means you can take advantage of features rather than relying on the most generic or completely portable features. If some hardware or compiler offers a feature you can take advantage of, then take advantage of it. You don't say things like "This hardware offers parallel processing, SIMD, lots of cores, and hardware acceleration for 3D graphics, but I'm going to stick with the basics. None of those fancy instructions or libraries, it is pure C++98, no threading, and all graphics will be done with direct hardware interaction." No, instead you look for features on the system and take advantage of them.

The language is less productive than many newer languages, but we don't use C++ for productivity reasons. We use it because the compilation model makes for incredible optimizations, because it allows programmers to control everything, because unlike other languages you only pay for features when you use them (with only two exceptions, exception handling and RTTI, and those are frequently disabled). We use it because it is trivially compatible with everything else. We use it because there is an enormous library of functionality to rely on. We use it because it allows extensions to take advantage of hardware. And when it is not the right language, we build scripting systems or exposed interfaces or can otherwise leverage high-productivity languages when performance is not key.

For systems level work, C#, Java, and other languages have much to be desired. C++ is great for systems level work. It is more productive than predecessors, and flexible enough for all your low level needs.

The problem is, C++ is a terrible language for dealing with large codebases.

Its insane compilation model leads to terrible build times, and completely breaks down in large codebases. A windows build of Qt5 takes >2 hours on a quad core system with a SSD. A comparable codebase in C# would take less than 10 minutes (my system manages ~100Kloc of C# per second, which would build the whole 10Mloc of Qt5 in 1.5 minutes.)

There are ways to mitigate this with good design. But yes, the C compilation model which C++ uses doesn't encourage it. That's why the C++ committee is looking into modules.

Its lack of garbage collection means that long-running applications will suffer from memory fragmentation issues unless special measures are taken.

Some people would consider lack of a garbage collector a huge benefit, especially in the gaming realm where you can't afford random framerate drops due to collections you can't control. Also, garbage collectors only manage memory - the do nothing to help you with other resources you must manage.

The lack of an ABI means that its impossible to create reusable components in a truly portable manner.

It's certainly a flaw, and various solutions have been proposed including CORBA, COM, and a paper for a C++ ABI is in the works to be submitted to the C++ committee.

The complexity of the specification means that no two compilers implement the language in a compatible manner. Portable code is littered with "#ifdef _MSC_VER > 1700" and similar line noise.

C++ may have been an improvement over C when it was created (debatable), but right now the main reason for its popularity is inertia.

Compilers are very good at following the standard now, this is not usually a problem anymore unless you're using an old version or some really new C++11/14 features.

Seems like you got burned by old C++ a while ago. I suggest checking it out again with a good compiler

You can do systems programming in C#, but the code will be uglier than the equivalent C++ code.
You can do gameplay programming in C++, but the code will be uglier than the equivalent C# code.

The last 4 console games I've worked on have used C++ for the engine and complex/high-performance gameplay systems, and LuaJIT for the rest.
The Jua GC did cause a lot of problems with per-frame performance and memory fragmentation though... So despite being 'easier', it became a huge challenge. We also miss C++'a RAII when moving on to other languages

There is nothing worse than starting out on a Java or .NET project only to realize that there is no up-to-date binding available for a technology I plan to use (which is extremely likely to provide a C API). That sinking feeling I get when I need to start messing about with JNI or .NET DLLImport code. What a waste of time when I could just be working on the game instead.

Whereas for C++ I can use the C libraries directly since C++ by design is an extension of C (so long as I am careful with smart pointers and deleter functions I can often get away without any abstraction layers at all).

I think this very reason is why most commercial software written today is still in C++. I think a lot of C# developers on these forums seem to forget that C# is only easy and safe because Unity has already done the actual hard work of writing the engine, binding the libraries and porting the .NET runtime to the many platforms (Same with OpenTK, and XNA-like).

As for the language itself I am not too bothered. C++, Java and C# is similar enough so long as you do not use the old crusty parts. I do however find Microsoft's C++/clr:safe very interesting. Basically a merge of C# and C++ so you get all the RAII and memory management goodness of C++ but also the safety of C#. Looking at the generated IL, Microsoft really could add RAII to C# and if it could also compile to native machine code (so it didnt need such a complex (to port) runtime VM), it would likely dominate the world.

Your actually all missing the key point of C++ it was mainly created to deal with larger and larger code bases that's why classes where created, for reusable code and then it evolved into a standardised lanuguage from there.

The problem is, C++ is a terrible language for dealing with large codebases.

C++ is still the best tool for dealing for large project if you need a proper memory management due performance reasons. The only actual alternative is called C, which provides you less features and is less friendly with large projects (note that less friendly doesn't mean you cant's use C instead of C++ to obtain the same result, the same applied to assembly).

Its insane compilation model leads to terrible build times, and completely breaks down in large codebases. A windows build of Qt5 takes >2 hours on a quad core system with a SSD. A comparable codebase in C# would take less than 10 minutes (my system manages ~100Kloc of C# per second, which would build the whole 10Mloc of Qt5 in 1.5 minutes.).

The insane compilation models comes basically from C since C compatibility is a feature of the language. Modern IDEs with modern compilers, librarians and linkers mitigate the compilation issue, however yes, some drastic changes would be appreciated, hopefully with C++17 the introduction of modules will cut the compilation times. Note also that a portion of the compilation time are due code analysis, adding debug information and low level micro-code optimizations (most of them are not suitable to language such Java and C#... oh yep, Microsoft is working on .net native so maybe they will learn something for speed-up compilation time). Speaking of a real-word large piece of software, today I get the UE 4.3 sources and it takes something like 45 minutes to compile from the beginning (ie no pch) all the project of the solutions (engine and tools) with VS2013 on a machine over 4 years old (i5 750).

Its lack of garbage collection means that long-running applications will suffer from memory fragmentation issues unless special measures are taken.

The lack of garbage collector is not an issue in a native programming language where manually memory management is a centrepiece of the language. If you build a system in C++ where memory fragmentation is an issue you are doing it wrong (guess: you are directly using the new and the delete operators everywhere without defining a custom allocator or at least a proper heap container such a pool).

The lack of an ABI means that its impossible to create reusable components in a truly portable manner.

C++11 provides a definition of what a GC can do if one is used and an ABI to help control its actions. C++ is a native programming language and imposing a full trict ABI would be infinitely stupid, it would destroy the freedom to implement the language in the best way for every single architecture, it would destroy a good part of the possible optimization offered by the language. The lack of a solid ABI and GC don't prevent you to make a project where C++ is used only where needed (games are a practical example of different pieces of code written in different languages coexisting with C\C++).

The complexity of the specification means that no two compilers implement the language in a compatible manner. Portable code is littered with "#ifdef _MSC_VER > 1700" and similar line noise.

The C++11 different compiler conformance status are related to the the length path that C++11 take to be developed, a long path due the stupidity of the ISO committee, that waited 13 years (!) to define a new standard.

Portable code is related to what the code does when it runs. Compiler version macros such "#ifdef _MSC_VER > 1700" are intended to used to make portable code (YES!) on different compilers (especially older versions) with different language version support. In other language such C# and Java you cannot target different compilers and language versions in a single source code if you are not using the least common multiple of the language supported features and libraries.

C++ may have been an improvement over C when it was created (debatable), but right now the main reason for its popularity is inertia.

Inertia? Maybe, but there are no still valid alternative... And no, C#, Java, Go, D are not alternatives to C and C++, since managed programming languages are not alternative to native programming languages, they are different tools for different prurpose. The problem is not the lack of ABI or of GC, the problem is why do you use a programming language without GC and ABI if you need them in your work?

There are only two kinds of languages: the ones people complain about and the ones nobody uses

C++ is a language that gives you control of how things work. This means you can do a lot of things, but you also need to handle all the steps, what includes managing your own memory (to name an easy one).

Being lower level than most languages makes it perfect for lower level work. That's why lots of games are done in C++ while they have a scripting layer. That makes a lot of sense, let's give ourselves full control over the performance sensitive part while using a cleaner language for the content and higher level portions.

Garbage collection, one of the most praised features of some languages, is perfectly possible in C++. Not only that, you have plenty of options to choose, from Boost to HBoehm, but I personally only seen them in use a couple of times. I am personally proud of my own memory pool implementation.

It is almost like using a screwdriver on screws and a hammer on nails. There'll be some times where you'll do things better in C++ than you could with Lua, and there'll be the opposite. You can try to attach the screwdriver to the hammer's handle, but what if you need a spoon?

Most people I know that have this completely negative view of C++ are the ones who got frustrated with it at some point and formed their opinion based on their initial experience. But well, I got frustrated with Java, I sincerely think it is an awful language that is just being kept alive by Android and inertia. Still, that's just my opinion here too, I don't have any trustworthy data to back it up.

Well, is C++ still being used due to inertia? In part, yes. Why? Because there's still no force strong enough to change that.

I can program well enough in C, C++, C# and Prolog. I have made some for-hire with PHP and MySQL. I think could risk my hand in Pascal, Ruby, Lua and maybe Octave. And I think I can choose well between these.

Inertia plays a big part, but the other reason is simply that C++ is currently the best, most-widely-available language we have at our disposal when you need to touch the hardware. At the lowest levels, doing the kinds of things that runtimes, drivers, and operating systems do, basically everyone speaks C or C++ -- there are other systems-languages with pockets of support, but in consumer software and consumer electronics, C and C++ are it. Then, it stands to reason that if you're writing any kind of high-performance app that needs to get the most of of those runtimes, drivers, and operating systems, using the same language will give you fastest and most authentic, transparent path. Stepping back one space, to achieve high-performance in code that isn't so much touching those underlying elements, you still need to employ the same kinds of low-level techniques that those elements use themselves -- for example, you might write a memory manager, or you might implement certain parts of the code using intrinsic or inline assembly, perhaps making use of instructions like SSE or AVX that aren't available to the VM models of languages like Java or C# -- and again C and C++ are the natural choice.

I think ultimately, it comes down to the fact that C and C++ are one of very few languages, and by far the most popular, that give full trust and confidence to the programmer that they are doing precisely what you want. C and C++ will let you shoot yourself in the foot, sure, but when you pull a gun, point to the ground and shout "Watch this!" C and C++ will almost never second guess that you know what you're doing unless you ask it to -- and even when it thinks better of it and objects, its not hard to convince it that you do, in fact, know what you're doing. This is a perilous but powerful relationship to have with a compiler, other languages are such hypochondriacs that not only will they prevent you from shooting yourself in the foot, they will also stand in your way when you want to undertake all kinds of unorthodox but supremely mundane activities, regardless of how well thought out of a plan you want to try to convince it you have.

That said, those other do-gooder languages are often enough fast enough and flexible enough for a great many things -- used well, and combined with a little arcane knowledge of their supporting run-times, they're even suitable for games. At some level underneath, there's a hidden sea of C and C++ doing all the things that C and C++ do to make stuff go fast, but those other languages are suited well enough for directing its current.

C++ is popular in games because it started doing a job that needed to be done before anyone else was ready to do it, and because no one since can do, or do such a better job at to make the switch worthwhile. There are other interesting systems languages available that are aimed at the consumer software space, D and Rust come to mind, but they don't now are aren't likely to have the necessary industrial support to turn the tide any time soon.

The reason build times are insanely huge is because of the compilation and linking model. Pull everything in. Inline everything you possibly can. Optimize and precompute everything possible, perform every optimization possible, restructure everything from the biggest algorithms to the smallest pigeon-hole to be cache friendly, OOO-core friendly, branch predictor friendly, lookahead table friendly, and more.

Cache-friendly C++ code? That's a good one.

C++ may be more cache-friendly than Java, but that's it. If you've ever done any high-performance DSP programming, it's C and assembly all the way. C++ compilers generate code that is simply too inefficient to compete (and that's *after* you disable exceptions, RTTI and ditch the STL.)

Keep in mind that these optimizations can be applied for pretty much any statically-typed language.

Compilers are very good at following the standard now, this is not usually a problem anymore unless you're using an old version or some really new C++11/14 features.

Seems like you got burned by old C++ a while ago. I suggest checking it out again with a good compiler

We have a large C++11 codebase (medical imaging) and I'm the one who keeps it running on Windows. Linux/G++ and Mac/clang++ are great - as soon as you move to any other compiler it's a frigging crapshoot. It's 2014 and a main compiler vendor can't properly implement a 4 year old specification. Wow.

Fun tidbit: I attempted to use TI's C++98 compiler to develop a hard real-time application on 2x6-core C6472 DSPs. My word of advice: don't. Even if the compiler followed the spec and (it doesn't) the generated code is simply... bad (to put it mildly.) The same vendor has a perfectly functional C compiler that produces excellent code for this platform - is their C++ compiler to blame, or is it that the C++ specification makes it very difficult to write a well-performing compiler?