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).
GC.free() can be used to manually delete GC-allocated data.
(destroy() must be called first to call te destructor, though) -
delete does both but is deprecated. You could write a simple RAII
pointer wrapper if you don't want to always call
destroy()+GC.free() manually.
Or do you need something else?
