So what exactly is coming with extended C++ support?

[Ethan via Digitalmars-d]

On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner 
wrote:
> Considered how many games (and I don't mean indie anymore, but 
> for example Blizzard's Heartstone) are now created in Unity 
> which uses not only GC but runs in Mono I am very skeptical of 
> anybody claiming GC is a no-go for games. - Especially- that 
> native executable is being built in case of D.
>
> I realize AAA's have have their reasons against GC i but in 
> that case one should probably just get UE4 license anyway.

Hello. AAA developer (Remedy) here using D. Custom tech, with a 
custom binding solution written originally by Manu and continued 
by myself.

A GC itself is not a bad thing. The implementation, however, is.

With a codebase like ours (mostly C++, some D), there's a few 
things we need. Deterministic garbage collection is a big one - 
when our C++ object is being destroyed, we need the D object to 
be destroyed at the same time in most cases. This can be handled 
by calling GC.collect() often, but that's where the next thing 
comes in - the time the GC needs. If the time isn't being 
scheduled at object destruction, then it all gets lumped together 
in the GC collect. It automatically moves the time cost to a 
place where we may not want it.

ARC garbage collection would certainly be beneficial there. I 
looked in to adding support at a language level and at a library 
level for it, but the time it would have taken for me to learn 
both of those well enough to not muck it up is not feasible. 
Writing a garbage collector that we have greater control over 
will also take up too much time. The simpler solution is to 
enforce coding standards that avoid triggering the GC.

It's something I will look at again in the future, to be sure. 
And also to be sure, nothing is being done in Unity to the scale 
we do stuff in our engine (at least, nothing in Unity that also 
doesn't use a ton of native code to bypass Unity's limitations).