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

[Paulo Pinto via Digitalmars-d]

On Tuesday, 30 September 2014 at 21:19:44 UTC, Ethan wrote:
> 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).

Thanks for the feedback, quite interesting.