[=]
I don’t think any blanket statements have been made advocating C++ as the only solution to any problem. I think the case has been made that there are downsides to any managed language, and that C# and IL languages in particular lack the comparative speed and language features relative to C++ and therefore make it a less optimum choice for a large complex real-time application.
No one is trying to make some kind of crusade for or against any particular language here.
[/]
Did you read the thread? There are quite a few garbage posts such as:
[]
Poor you.
You must understand that:
a) This is gaming industry and so it follows:
In order to have best performance you have to use C++.
In order to have best flexibility you have to use C++.
In order to have AAA games with AAA performance/visuals you have to use C++.
Get it!
No java, c# or other slow mo creature can provide you with it. Get it, deal with this and be grateful…
[/]
The comment you were referring to was directed at posts such as these.
Note that in my reply, I did state that native code is a very appropriate choice for many of the performance critical subsystems in the engine; but may be significantly less so for game logic, AI, networking code and so on (i.e. a majority of the game-specific logic you may wish to implement).
[]
This is a bad generalization in my opinion. Domain specific knowledge is critical in certain classes of problems, but that does not mean that language choice is irrelevant by any means. There are trade-offs.
[/]
Of course there are trade offs. My point was simply to state that if you cannot enumerate the exact reasons why writing code in a particular language, and using particular language features that aren’t available in other languages, then you are not qualified to make the statement “X is faster than Y”. That’s because C++ being inherently faster than C# is a myth. Writing the same logic in either language will produce fairly similar results in regards to performance; unless you are specifically taking advantage of things that are impossible to replicate in C#.
[]
Generally speaking, across an application, C# is slower than C++, ranging from 2x to possibly many times slower…
[/]
This is untrue. C# is compiled into IL, IL is compiled (at runtime) into machine code. There are certain things that the runtime does that makes it slightly slower (array references are bounds-checked for example - though scoff at this all you want, but this feature has removed a metric crapload more critical (and potentially security related) bugs than C#'s lack of constness has added). However, for the most part, the machine code produced by a .net assembly will be very similar to that produced by C++. The biggest performance hit is the time it takes to warm up - but this only affects startup times (and the first time a method is invoked) but can be completely eliminated by using a tool such as nGen.
[]
But UE4 is meant to push the bleeding edge. Potentially losing a factor or 2x or more off the top of a program just based on your choice of language before you write any code at all is a discussion worth having.
[/]
As I said before; C# is not a good choice for the core engine and certain sub-systems such as collision detection, physics simulation or rendering. That’s because these are general systems (that don’t require per-game modification) and that are maintained by a team of expert developers who have the time and energy to optimize them, all day, every day. Many other systems, the kinds that a gameplay programmer, tool developer, or AI developer would write are not performance critical. Giving them a leg up in productivity and correctness is worth a slight performance hit - hell, while this figure is absolutely incorrect, I’d even say a 2x performance hit is more than worth it. Remember: these systems do not need to be executed many times in a frame.
And what if, one day, they do need to write something performance critical? They can still certainly jump into C++ and make their modifications that way.
[]
There are no inherent stability advantages or disadvantages inherent to either language, except for garbage collection. The good and bad of GC in a real-time application is a big topic. It’s also not a trivial issue. GC cycle hitches in Unity are a real issue.
[/]
Safety Features:
- Array bounds checking
- Better type safety
- An exception system that developers aren’t embarrassed to use
- No raw/dangling pointers
- Requirement that variables be definitely assigned before access
OO Features:
- Interfaces
- Better enums
- Lack of multiple inheritance (I’ve yet to see a proper use-case of multiple inheritance in C++, except in the case where classes with only pure virtual methods are used to emulate interfaces). This especially holds true as the programming industry, at large, now discourages heavy use of inheritance in favor of composition-based OO strategies.
- Arguably better generic type system. C++ templates are glorified macros, while generics in C# are baked straight into the runtime. 90% of cases where C# generics can’t emulate something that you can do with C++ templates are unnecessary in C# - such as traits. Furthermore, generics in C# do not affect the size of the assembly, nor the time it takes to compile.
Runtime Features:
- Proper reflection - which includes instantiating generic types at runtime. Yes, reflection can be emulated in C++ though heavy use of templates, but this adversely affects compile times as well as runtime performance.
- Type safe dynamic code generation via expression trees
Other Features:
- Unicode (UTF-16) is baked straight into the framework and requires no additional thought. The existence of a string primitive (and lack of support of C-style strings) removes complexity and increases compatibility with third party code.
- The existence of a delegate type. This, yet again, can be emulated in C++ though clever use of templates and other features - yet, delegates are a first class citizen of the .net world.
Productivity Features:
- Much, much (much much much much) faster compile times
- Visual 's C# support, combined with ReSharper, destroy any toolset of any language I have come into contact with. Ever.
- The way in which the compiler handles errors (C++ errors, especially linker errors, can be quite cryptic)
[]
The expressive power of C++ as compared to C# allows for significantly more elegant and powerful code architecture. Slate in UE4 is a good example of this. In-fact the entire Unreal Object system is a living breathing example of the type of architectural expressiveness allowed by C++ that would never be possible in C#.
[/]
C++ is hardly more “expressive” than C#. C++ is a hodgepodge of features that, with dedication and discipline, can be cobbled together into sensible code. Most of the time, however, these “expressive” features of C++ are simply used to emulate features that are inherently available in C# and other .net languages. Slate is some sort of odd subset of C++ that cleverly uses some of C++'s unique features (such as C++'s obscene list of overloadable operators) to create a programming experience that is some kind of imitation of a C# like language combined with a declarative DSL.
Furthermore, it may have been advantageous for Epic to have created an actual, outside-of-C++, DSL for slate layout files. Creating DSLs is incredibly easy to do in C#, especially with tools such as Antlr - and if you combine them with the dynamic code generation features of C#, they can have the same performance characteristics of straight-up managed code.
Also, what do you mean by:
[]
the ability to do full static analysis
[/]
?
You can statically analyze C# pretty easily; and, in fact, it is much faster and less error prone to do so.