Exactly.

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.

C# has support for stack-allocated "struct" objects that avoid the GC. They have their limitations and gotchas, being somewhere between simple C structs and C# classes, but they exist.

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.

I am also looking forward to the .NET Native C# compiler release.

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.

I feel like I should point out that the stack is an implementation detail [1]

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...

Regardless, C# has a linguistic feature that provides objects with stack-like performance and copy-by-value semantics familiar to C developers.

There is heavy rumors going around that a new version of C# with a more well defined memory model is in the works.

It doesn't have to be an all or nothing proposition with C# or C++ anymore if Windows is your target environment. You can write the portions you want to write in C# and mix it in with C++/CLI. Yeah, I know, a lot of people think C++/CLI is ugly, but in the .NET world, it is a very clean glue language if you can get past the strangeness of having two different type systems (native and managed.)

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.

Note that Unreal uses a C++ GC.

Totally different from C#:sa GC.

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++.

Well, since C++11, C++ also has a standard minimal GC API, although only VC++ supports it currently.

Thanks for the clarification, as I only knew there was a GC from gamedev articles, forums, without much details.

I'm neither an Unreal nor a C++ expert, but I assume that this kind of GC still allows exact control over when the collection happens since it's not language- but a library feature. In this case this should still be better for game engine purposes, since the GC can for example be hidden behind GPU rendering time.

C++ has a GC API since C++11.

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.