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.

You make it sound like a C++ game codes, debugs, profiles and optimizes itself.
And like there are no gotchas with C++.

> Anyway, I know I'm on a D forum here, so "those who don't want to understand won't, and those who want will", to paraphrase a former poster here.

Well, it appears that you don't.

And since you point out the D forum folks, I know game developers are a very special lot, too, with ther mantra like repetition of GC is the devil, acting like it's 1985 and the need to count clock cycles and top-of-the-food-chain I-never-make-mistakes arrogance like nobody else knows how to write fast code, yet most games of those clever guys are bug ridden pieces of poor quality even years after release, including top AAA titles *cough* TES. Despite - or more likely because - being made in C++.

Maybe performance aware game developers would do well to also adopt the idea of code quality and D offers a lot in that regard. Plus C++ish performance on top of that.

On Friday, 6 July 2018 at 17:26:26 UTC, wjoe wrote:
> And since you point out the D forum folks, I know game developers are a very special lot, too ...

Edit: This should read: I know game developers who are a very special lot

My point was to only refer to the people I know, not game developers in general.

On Friday, 6 July 2018 at 17:26:26 UTC, wjoe 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.
>
> You make it sound like a C++ game codes, debugs, profiles and optimizes itself.
> And like there are no gotchas with C++.
>
>> Anyway, I know I'm on a D forum here, so "those who don't want to understand won't, and those who want will", to paraphrase a former poster here.
>
> Well, it appears that you don't.
>
> And since you point out the D forum folks, I know game developers are a very special lot, too, with ther mantra like repetition of GC is the devil, acting like it's 1985 and the need to count clock cycles and top-of-the-food-chain I-never-make-mistakes arrogance like nobody else knows how to write fast code, yet most games of those clever guys are bug ridden pieces of poor quality even years after release, including top AAA titles *cough* TES. Despite - or more likely because - being made in C++.
>
> Maybe performance aware game developers would do well to also adopt the idea of code quality and D offers a lot in that regard. Plus C++ish performance on top of that.

Yeah. There are plenty of games done in GC languages. C++ folks want to use C++. The ones that wanted to switched, switched already. Even if nogc gets more mature, they will find another excuse. Probably something like "yeah but now I don't know which parts of the language and library I can use and it's awkward to put nogc everywhere".

I do some free time game development work in various languages, even GC ones and the existence of GC was never a big issue for me. Sure, I am not a super mighty C++ programmer, so I don't know much, but for me it's more important as a gamedev to have features such as operator overloading, value types/be able to cast Vector3f[] to float[] without copying (something C/C++/D can do, for example Java can't do, C# can partially do that with LayoutKind.Sequential), accessibility of C bindings for popular libraries like SDL, SFML, ODE.

nogc, betterC, interfacing to C++, at most they get a "hmm, that's interesting", but I haven't really seen them bring people to D. And I'll take a fun and convenient language over performant one any day.

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.

On Friday, 6 July 2018 at 17:22:15 UTC, 12345swordy wrote:
> On Friday, 6 July 2018 at 17:16:54 UTC, Ecstatic Coder wrote:
>>> Are you seriously going to ignore video games that are entirely implemented in GC focus language such as C#/java?! The GC is NOT AN ISSUE IF YOU KNOW WHAT YOU ARE DOING!
>>>
>>> -Alexander
>>
>> +1
>
> You are start reminding me of another person who pull these type of stunts. Which is not a good thing btw, as that guy is a notorious troll.
>

So if I agree with you, then I'm a troll ?

>> While ANY C++ game can make ANY number of allocations/allocations inside a game loop and still run without a risking any freeze.
> You are doing something very wrong if you are doing this.
>
> -Alexander

Just try it.

Inside the game loop, add a for loop which evaluates the score text 100 times as explained above.

Or even 1000 times.

This means roughly 2000 allocations and 1999 deallocations.

Your frame rate suffer will suffer from this, which is bad (and as such should absolutely avoided) but zero risk of garbage collection freeze.

Then add ONE time the "naive" text score concatenation in the game loop of a garbage collected loop, and you expose yourself to a RISK of a garbage collection freeze. Just because of ONE string concatenation, executed only once per frame, which is something that could be tolerated in a C++ game.

On Wednesday, 4 July 2018 at 20:17:59 UTC, Maksim Fomin wrote:

> I am from area of economic, financial and scientific calculations used in decision making.

So am I.

> It is hard for me to provide arguments for using D (meaning from professional area view) because c++ can be used for performance and D is poor in statistical libraries. Because it is applied area nobody cares whether exceptions have root class or whether virtual is default.

What statistical libraries do you need? I can embed an R interpreter inside a D program, so D provides all R functionality. Furthermore, any compiled code for which there is an R interface also has a D interface. There are various C libraries that are easy enough to call from D. At least for the things I do, I have not run into any constraints librarywise, though sometimes I have to do a little work to call into existing libraries.

On Friday, 6 July 2018 at 17:43:29 UTC, JN wrote:
> On Friday, 6 July 2018 at 17:26:26 UTC, wjoe 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.
>>
>> You make it sound like a C++ game codes, debugs, profiles and optimizes itself.
>> And like there are no gotchas with C++.
>>
>>> Anyway, I know I'm on a D forum here, so "those who don't want to understand won't, and those who want will", to paraphrase a former poster here.
>>
>> Well, it appears that you don't.
>>
>> And since you point out the D forum folks, I know game developers are a very special lot, too, with ther mantra like repetition of GC is the devil, acting like it's 1985 and the need to count clock cycles and top-of-the-food-chain I-never-make-mistakes arrogance like nobody else knows how to write fast code, yet most games of those clever guys are bug ridden pieces of poor quality even years after release, including top AAA titles *cough* TES. Despite - or more likely because - being made in C++.
>>
>> Maybe performance aware game developers would do well to also adopt the idea of code quality and D offers a lot in that regard. Plus C++ish performance on top of that.
>
> Yeah. There are plenty of games done in GC languages. C++ folks want to use C++. The ones that wanted to switched, switched already. Even if nogc gets more mature, they will find another excuse. Probably something like "yeah but now I don't know which parts of the language and library I can use and it's awkward to put nogc everywhere".
>
> I do some free time game development work in various languages, even GC ones and the existence of GC was never a big issue for me. Sure, I am not a super mighty C++ programmer, so I don't know much, but for me it's more important as a gamedev to have features such as operator overloading, value types/be able to cast Vector3f[] to float[] without copying (something C/C++/D can do, for example Java can't do, C# can partially do that with LayoutKind.Sequential), accessibility of C bindings for popular libraries like SDL, SFML, ODE.
>
> nogc, betterC, interfacing to C++, at most they get a "hmm, that's interesting", but I haven't really seen them bring people to D. And I'll take a fun and convenient language over performant one any day.

As I said, I wanted to explain the roots of the GC phobia for some C++ developers.

If you don't agree when I said that one allocation during a C++ game loop is no problem, which one allocation during a GC language game loop MAY eventually become a problem, that's fine by me.

But as many people here told me to "disable the GC" to completely avoid this potential risk of game freeze, I guess that all those D experts are also wrong in giving me this advice.

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.

On Friday, 6 July 2018 at 17:59:27 UTC, Ecstatic Coder wrote:


>>> While ANY C++ game can make ANY number of allocations/allocations inside a game loop and still run without a risking any freeze.
>> You are doing something very wrong if you are doing this.
>>
>> -Alexander
>
> Just try it.
For what rhyme or reason!? You shouldn't be allocating and deallocating inside a critical loop in the first place!
Regardless people have shown you solutions regarding string concatenation. Are you going to address that or you just going to ignore them?

-Alexander

On Friday, 6 July 2018 at 19:22:13 UTC, 12345swordy wrote:
> On Friday, 6 July 2018 at 17:59:27 UTC, Ecstatic Coder wrote:
>
>
>>>> While ANY C++ game can make ANY number of allocations/allocations inside a game loop and still run without a risking any freeze.
>>> You are doing something very wrong if you are doing this.
>>>
>>> -Alexander
>>
>> Just try it.
> For what rhyme or reason!? You shouldn't be allocating and deallocating inside a critical loop in the first place!
> Regardless people have shown you solutions regarding string concatenation. Are you going to address that or you just going to ignore them?
>
> -Alexander

Also when I used the word phobia I was pretty sure that I was referring to irrational fear of things. Big emphasis on the word "irrational".

-Aleaxander