What's most distressing is people (as normal) are completely ignoring the garbage collection overhead, which is mostly where the advantage of having complete control is, in terms of micro-managing your memory allocation, e.g. using slab allocators, memory pools, pre-allocation, etc.
C# code in theory (ignoring things like intrinsics support and inline asm) can be as fast as C++ for tight loops, but in my experience (writing 2D/3D software for the VFX industry) +85% of the time if you profile something, it'll be the memory allocation which is killing things performance wise.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n267...
Currently Visual C++ is the only C++ compiler offering support for it.
As for Unreal, I only know it has one by reading game development foruns. I don't know what type of control it offers.
The GC in unreal engine is used to know when what entity should be removed from the game. (If you have multiple entities pointing each other.)
The memory allocation still works how it works in C++.
Thanks for the clarification, as I only knew there was a GC from gamedev articles, forums, without much details.
GC-based languages run games on many, many platforms. The problem, imho, is that you have to leave 90% of the language features on the shelf when you're doing your main loops in order to avoid triggering the GC.
The gaming industry is practically begging for a language like Rust.
Mostly as a way for young generations to finally grasp GC/memory safe != VM, as they seem to have been brainwashed since Java became widespread.
Though in this context it's relevant to point out pretty much any implementation will stack allocate them, it's not accurate to say C# has stack allocated objects.
[1] http://blogs.msdn.com/b/ericlippert/archive/2009/04/27/the-s...
You can essentially choose and manage how you want to deal with memory by virtue of how you choose between native and managed types, as well as control the behavior of the garbage collector itself.