[=;15529]
The main problem with C++ is that programmers think too highly of themselves, run out of talent, and introduces multiple memory stomps that other guys have to spend time tracking down and resolving.
I do believe C# is the future going forward without a doubt. But for now, C++ is still king of performance and memory management. I think it’s a great idea for the core of the engine to be written in C++ but game code can be higher level (byte code, etc)
Where Epic Games went wrong in the past was UnrealScript. Which kept me away from UDK. It couldn’t be debugged, couldn’t rapid prototype, took awhile to compile, etc. It had all the disadvantages of a scripting language and none of the bonuses lol
[/]
It is a common fallacy that C# performs worse than C++. C# and C++ can perform equally well when compiled to native code because C# is optimized in the same manner as C++ and in some cases better. It is true that the default behavior is to compile C# to IL, however, this can be changed. Even still, C# has a just-in-time-compile feature, which means the first time an application’s execution path leads to IL, it is compiled to native code and from that point on it’s just as fast as anything else compiled to native code. However, C# and managed languages have other issues at run time, which make them challenging for games development. This is also the reason managed languages will NEVER be used for game engines. I’m sure there are examples of attempts to make a game engine in C# but it will never be a serious contender in the AAA world.
C# and other managed languages are only the future for applications where more hardware is the solution to memory and performance problems, aka business applications. In games, memory management is super important and managed languages don’t really offer the degree of control you need in most cases. For example, garbage collection will cause rather large lag spikes if you don’t consider strategies to deal with this. If I create an instance of an object each frame at 60 frames a second, it means I’m creating 60 instances of garbage that needs to be collected each frame. If I extrapolate that out over many objects, you can see that the garbage collector could easily become overwhelmed as significant pressure is applied to the CPU during garbage collection, which causes a visible drop in frame rate. In a large game, this can become very difficult to manage. In severe cases you can see situations where the game skips every couple of seconds due to garbage collection. Having shipped several games in Unity3D, this is a huge problem, which typically requires strategies like object pooling but, even with strategies like this, it’s still a real pain to deal with. In C++ you have complete control over memory so you can make it work exactly the way you need it to work, rather than being forced to deal with a memory management solution that is not optimized for games.
In C#, resolving a property on a reference type requires a memory read where resolving a property on a struct does not because it’s a value type that lives on the stack. Also, value types can be boxed inside a reference types (aka object), so you need to be aware of this. While this is a very minor optimization example, it’s one of many you have to be aware of when dealing with managed languages that either don’t apply or have a more elegant solution in C++. The bottom line is that managed languages have a place in games but it’s not the future. Business applications are different story because they usually don’t have the same type of performance and memory requirements that games do.
When looking at what language is the best tool for the job, it’s important to consider both functional requirements AND non-functional requirements, aka memory and performance…
