I have a plan.. I really DO

[Ecstatic Coder]

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