On Friday, 6 July 2018 at 18:19:08 UTC, Ecstatic Coder wrote:
> Because in C++, smart pointers and collections will make sure to free unused memory block as soon as they need to, and no later.

I bet if D was reference counted from the start, C++ programmers would complain about "smart pointer overhead" and how ref counting is too slow for games/real time and you should be able to manage your memory yourself.

On Friday, 6 July 2018 at 19:56:23 UTC, JN wrote:
> On Friday, 6 July 2018 at 18:19:08 UTC, Ecstatic Coder wrote:
>> Because in C++, smart pointers and collections will make sure to free unused memory block as soon as they need to, and no later.
>
> I bet if D was reference counted from the start, C++ programmers would complain about "smart pointer overhead" and how ref counting is too slow for games/real time and you should be able to manage your memory yourself.

Probably ;)

On Friday, 6 July 2018 at 19:27:51 UTC, 12345swordy wrote:
> 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

Irrational would mean this would be impossible to have a GC freeze because of just one string concatenation during the game loop of a garbage collected language.

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

Pfff, it was just an EXAMPLE of how some insignificant string concatenation code may eventually be a problem in any GC language even if it's done only once per frame.

I've never said that this is something smart to do. I'm just saying that this code can perfectly be executed once in a C++ game frame without having to worry for a game freeze, because the string buffer deallocation is done once per frame too.

While with many GC languages, you actually DON'T KNOW when all those unused string buffers will be claimed.

This ignorance is, in my opinion, the root of this "phoebia".

If you disagree with me, fine. No problem. Maybe I'm wrong.

But this is my opinion. Please feel free to ignore it.

On Fri, Jul 06, 2018 at 08:16:36PM +0000, Ecstatic Coder via Digitalmars-d-announce wrote: [...]
> I've never said that this is something smart to do. I'm just saying that this code can perfectly be executed once in a C++ game frame without having to worry for a game freeze, because the string buffer deallocation is done once per frame too.
> 
> While with many GC languages, you actually DON'T KNOW when all those unused string buffers will be claimed.
[...]

As I've already repeated twice, this is not true in D. You *can* predict precisely when the GC runs a collection cycle by calling GC.disable and then calling GC.collect according to *your* own schedule.  This is not just a theoretical thing.  I have actually done this in my own projects, and it does work.

Of course, for someone looking for an excuse not to use D, they will always find another reason why this is not sufficient. But that only strengthens the point that the GC is just a convenient excuse not to use D. Solve that problem, and they will just move on to the next excuse, because the GC is not the real reason; the real reason is probably non-technical. Like good ole inertia: people are lazy and set in their ways, and resist changing what they've grown comfortable with. But actually admitting this would make them look bad, so it is easier to find a convenient excuse like the GC (or whatever else is different from the status quo).


T

-- 
Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce

 Friday, 6 July 2018 at 21:15:46 UTC, H. S. Teoh wrote:
> On Fri, Jul 06, 2018 at 08:16:36PM +0000, Ecstatic Coder via Digitalmars-d-announce wrote: [...]
>> I've never said that this is something smart to do. I'm just saying that this code can perfectly be executed once in a C++ game frame without having to worry for a game freeze, because the string buffer deallocation is done once per frame too.
>> 
>> While with many GC languages, you actually DON'T KNOW when all those unused string buffers will be claimed.
> [...]
>
> As I've already repeated twice, this is not true in D. You *can* predict precisely when the GC runs a collection cycle by calling GC.disable and then calling GC.collect according to *your* own schedule.  This is not just a theoretical thing.  I have actually done this in my own projects, and it does work.
>
> Of course, for someone looking for an excuse not to use D, they will always find another reason why this is not sufficient. But that only strengthens the point that the GC is just a convenient excuse not to use D. Solve that problem, and they will just move on to the next excuse, because the GC is not the real reason; the real reason is probably non-technical. Like good ole inertia: people are lazy and set in their ways, and resist changing what they've grown comfortable with. But actually admitting this would make them look bad, so it is easier to find a convenient excuse like the GC (or whatever else is different from the status quo).
>
>
> T

+1

On Friday, 6 July 2018 at 20:16:36 UTC, Ecstatic Coder wrote:
> Pfff, it was just an EXAMPLE of how some insignificant string concatenation code may eventually be a problem in any GC language even if it's done only once per frame.

It does not matter that your point is a example. People will rip it apart a dozen times.  "the only winning move is not to play."

D will never be a industry accepted game engine replacement language ( beyond the few hard core people ). The whole GC is irrelevant from the start. Without GC D is barely a better C. With GC your forced to do more work to avoid the GC issues ( compared to C++ ). D has almost no resources for game developer. Few qualified D developers. Let alone the resource that are required. And the issues.

No company in their right mind will ever pick D for developing a **high performance** game engine. D barely keeps up with there own internal issues. So this idea that D has any hope as a Game Engine language ( beyond hobby projects and the oneof company with some D die hards ), is just ridiculous.

There is simply more change for a new language with more public traction to be picked for game engines in the future if C++ dies out, then D. That is a fact.

And a person does not need to be a troll to dare say this. D has a limited growth and its easy to see...

Just 6 days ago i posted this here:

> Total 1336 packages found.
> 3359 total shards

D has had a major release.
Crystal has had a minor release.

> Total 1339 packages
> 3382 total shards

D has gained 3 packages. Crystal has gained 23 packages.

Lets trow from a different angle. Updates: Crystal has 37 shard updates in 24 hours. D has 7 packages updates in the same time.

If a 16 year old language that pushes itself as a C++ replacement language can not keep up with a newcomer like language. And dare i mention Go, Rust, ...

I see a lot of people talking on the D forum. But few actually do a lot. I see few people talking on Crystal forums but a lot of people actually busy coding. Different mindset?

If i can be frank, even if the D community magically solves a lot of their internal issues, its hard to make a comeback in this industry. Its like Pascal has a change to become popular again. And i am sure that Pascal people will defend their languages just as much as the D people, pointing out more downloads and more activity.

On Friday, 6 July 2018 at 23:27:57 UTC, RhyS wrote:
>
>> Total 1336 packages found.
>> 3359 total shards
>
> D has had a major release.
> Crystal has had a minor release.
>
>> Total 1339 packages
>> 3382 total shards
>

This is a really weak point, because it doesn't show the quality of the packages.

Just look at npm.

> As I've already repeated twice, this is not true in D. You *can* predict precisely when the GC runs a collection cycle by calling GC.disable and then calling GC.collect according to *your* own schedule.  This is not just a theoretical thing.  I have actually done this in my own projects, and it does work.

Sorry, can you help me with this?

Eg.
void doit()
{
    int[] x;
    x.length = 1024 * 1024 * 128;
}

void main()
{
    import core.memory : GC;
    import core.thread;
    GC.disable;

    doit; //alloc +- 500mb inside the func.
    Thread.sleep(5.seconds); //500mb still in use.
    GC.collect; //hmmm still there
    Thread.sleep(5.seconds); //same
}

On Tue, Jul 10, 2018 at 04:07:01PM +0000, SrMordred via Digitalmars-d-announce wrote:
> > As I've already repeated twice, this is not true in D. You *can* predict precisely when the GC runs a collection cycle by calling GC.disable and then calling GC.collect according to *your* own schedule.  This is not just a theoretical thing.  I have actually done this in my own projects, and it does work.
> 
> Sorry, can you help me with this?
> 
> Eg.
> void doit()
> {
>     int[] x;
>     x.length = 1024 * 1024 * 128;
> }
> 
> void main()
> {
>     import core.memory : GC;
>     import core.thread;
>     GC.disable;
> 
>     doit; //alloc +- 500mb inside the func.
>     Thread.sleep(5.seconds); //500mb still in use.
>     GC.collect; //hmmm still there
>     Thread.sleep(5.seconds); //same
> }
[...]

AFAIK, the current GC does not release memory back to the OS. So you won't see the memory footprint decrease.  However, it does free up memory for subsequent allocations.


T

-- 
It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton