<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 4 February 2014 10:19, Adam Wilson <span dir="ltr"><<a href="mailto:flyboynw@gmail.com" target="_blank">flyboynw@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, 03 Feb 2014 15:26:22 -0800, Frustrated <<a href="mailto:c1514843@drdrb.com" target="_blank">c1514843@drdrb.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Monday, 3 February 2014 at 21:42:59 UTC, Shammah Chancellor<br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
You can always force the GC to run between cycles in your game, and<br>
turn off automatic sweeps.  This is how most games operate nowadays.<br>
It's also probably possible to create a drop-in replacement for the GC<br>
to do something else.   I could see if being *VERY* useful to make the<br>
GC take a compile-time parameter to select which GC engine is used.<br>
</blockquote>
<br>
<br>
This is just non-sense. Maybe this is why modern games suck then?<br>
How do you guarantee that the GC won't kick in at the most<br>
inopportune times? Oh, you manually trigger it? When? Right at<br>
the moment when the player is about to down the boss after a 45<br>
min fight?<br>
<br>
Oh, right.. you just segfault cause there is no memory left.<br>
<br>
On Monday, 3 February 2014 at 22:51:50 UTC, Frank Bauer wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not quite sure that I understand what you mean by GC avoidance being a major focus of 2014 though. In the long term, can I look forward to writing an absolutely, like in 100 %, like in guaranteed, GC free D app with all of current D's and Phobos' features if I choose to? Or does it mean: well for the most part it will avoid the GC, but if you're unlucky the GC might still kick in if you don't pay attention and when you least expect it?<br>

</blockquote>
<br>
It's either got to be 100% or nothing. The only issue of the GC<br>
is the non-determinism.... or if you do corner it and trigger it<br>
manually you end up with exactly the types of problems Mr.<br>
Chancellor thinks doesn't exist... i.e., the longer you have to<br>
put off the GC the worse it becomes(the more time it takes to run<br>
or the less memory you have to work with).<br>
<br>
</blockquote>
<br></div>
Why is this myth of non-determinism still alive? The only truly non-deterministic GC's are concurrent collectors, but alas concurrent collects don't routinely stop-the-world either, so there really aren't any pauses to complain about. D's Mark-Sweep GC is *perfectly* deterministic. It can  *only* pause on allocation. Ergo you can determine exactly which allocation caused the problem. You might not expect the function you called to GC-allocate, but that doesn't make it non-deterministic, just not what you expected. Please, stop blaming your missed expectations on the GC. This non-determinism thing is a red herring that is repeated over and over by people who obviously have no idea what they are talking about.</blockquote>
<div><br></div><div>Your assertion makes the assumption that people who write huge complex programs have completely control over their code, and/or depend on zero libraries, which is a ridiculous notion.</div><div>I'm quite sick of people making claims like that. If the default is to do something incompatible with my use case, and I depend on any libraries (including phobos), then it's safe to say, I'm running code that is incompatible with my use case.</div>
<div>What are my options then?</div><div><br></div><div>Additionally, in D, you don't have to type 'new' to allocate memory, it happens all the time... a closure here, a concatenate there. These are core language features, and to say that I'm meant to avoid them in my million loc program, authored by perhaps hundreds of programmers, because I need to be certain where every alloc is being issued from, is quite unrealistic to say the least.</div>
</div></div></div>