On Friday, 6 July 2018 at 17:58:46 UTC, bachmeier wrote:
On Friday, 6 July 2018 at 15:53:56 UTC, Ecstatic Coder wrote:
With D, ANY forgotten allocation during the game loop (and I
really mean even JUST ONE hidden allocation somewhere in the
whole game or engine), may cause the game to regularly freeze
at the wrong time, because of an unwanted GC. Hence the phobia.
This program
import std.conv, std.stdio;
@nogc void main() {
int point_count = 3;
string score = point_count.to!string() ~ " POINTS";
writeln(score);
}
provides this compiler output
nogc.d(5): Error: @nogc function 'D main' cannot call non-@nogc
function 'std.conv.to!string.to!int.to'
nogc.d(5): Error: cannot use operator ~ in @nogc function 'D
main'
nogc.d(6): Error: @nogc function 'D main' cannot call non-@nogc
function 'std.stdio.writeln!string.writeln'
Are you saying there are bugs in the @nogc implementation?
Otherwise I don't see how you will end up with a forgotten
allocation.
I agree.
But that feature is not something present in all the garbage
collected language.
The problem with my "naive" text score code is that you can trust
the C++ version to deallocate the destroyed string buffers "on
the fly".
Because in C++, smart pointers and collections will make sure to
free unused memory block as soon as they need to, and no later.
For the garbage collected language version, it's up to the
garbage collector to decide when and how this memory will be
claimed. So sometimes this may happen at the wrong time too...
So I'm not saying that D can't work with the GC disabled, etc.
I'm saying that you will find it hard to convince many C++ game
developers that they can make a few allocations within a game
loop in a garbage collected language like Java, C#, etc, and not
have to worry about that.
And by saying, "just disable the garbage collector", you are
convincing them still more of that, instead of the contrary.
