Smart pointers instead of GC?

[Shammah Chancellor]

On 2014-02-03 23:00:22 +0000, woh said:
> 
> On Monday, 3 February 2014 at 21:42:59 UTC, Shammah Chancellor wrote:
>> On 2014-02-01 07:35:44 +0000, Manu said:
>> 
>>> On 1 February 2014 16:26, Adam Wilson <flyboynw at gmail.com> wrote:
>>> On Fri, 31 Jan 2014 21:29:04 -0800, Manu <turkeyman at gmail.com> wrote:
>>> 
>>> On 26 December 2012 00:48, Sven Over <dlang at svenover.de> wrote:
>>> 
>>>  std.typecons.RefCounted!T
>>> 
>>> core.memory.GC.disable();
>>> 
>>> 
>>> Wow. That was easy.
>>> 
>>> I see, D's claim of being a multi-paradigm language is not false.
>>> 
>>> 
>>> It's not a realistic suggestion. Everything you want to link uses the GC,
>>> and the language its self also uses the GC. Unless you write software in
>>> complete isolation and forego many valuable features, it's not a solution.
>>> 
>>> 
>>>  Phobos does rely on the GC to some extent. Most algorithms and ranges do
>>> not though.
>>> 
>>> 
>>> Running (library) code that was written with GC in mind and turning GC off
>>> doesn't sound ideal.
>>> 
>>> But maybe this allows me to familiarise myself more with D. Who knows,
>>> maybe I can learn to stop worrying and love garbage collection.
>>> 
>>> Thanks for your help!
>>> 
>>> 
>>> I've been trying to learn to love the GC for as long as I've been around
>>> here. I really wanted to break that mental barrier, but it hasn't happened.
>>> In fact, I am more than ever convinced that the GC won't do. My current #1
>>> wishlist item for D is the ability to use a reference counted collector in
>>> place of the built-in GC.
>>> You're not alone :)
>>> 
>>> I write realtime and memory-constrained software (console games), and for
>>> me, I think the biggest issue that can never be solved is the
>>> non-deterministic nature of the collect cycles, and the unknowable memory
>>> footprint of the application. You can't make any guarantees or predictions
>>> about the GC, which is fundamentally incompatible with realtime software.
>>> Language-level ARC would probably do quite nicely for the miscellaneous
>>> allocations. Obviously, bulk allocations are still usually best handled in
>>> a context sensitive manner; ie, regions/pools/freelists/whatever, but the
>>> convenience of the GC paradigm does offer some interesting and massively
>>> time-saving features to D.
>>> Everyone will always refer you to RefCounted, which mangles your types and
>>> pollutes your code, but aside from that, for ARC to be useful, it needs to
>>> be supported at the language-level, such that the language/optimiser is
>>> able to optimise out redundant incref/decref calls, and also that it is
>>> compatible with immutable (you can't manage a refcount if the object is
>>> immutable).
>>> 
>>> The problem isn't GC's per se. But D's horribly naive implementation, 
>>> games are written on GC languages now all the time (Unity/.NET). And 
>>> let's be honest, games are kind of a speciality, games do things most 
>>> programs will never do.
>>> 
>>> You might want to read the GC Handbook. GC's aren't bad, but most, like 
>>> the D GC, are just to simplistic for common usage today.
>>> 
>>> Maybe a sufficiently advanced GC could address the performance 
>>> non-determinism to an acceptable level, but you're still left with the 
>>> memory non-determinism, and the conundrum that when your heap 
>>> approaches full (which is _always_ on a games console), the GC has to 
>>> work harder and harder, and more often to try and keep the tiny little 
>>> bit of overhead available.
>>> A GC heap by nature expects you to have lots of memory, and also lots 
>>> of FREE memory.
>>> 
>>> No serious console game I'm aware of has ever been written in a 
>>> language with a GC. Casual games, or games that don't attempt to raise 
>>> the bar may get away with it, but that's not the industry I work in.
>> 
>> You can always force the GC to run between cycles in your game, and
>> turn off automatic sweeps.  This is how most games operate nowadays.
>> It's also probably possible to create a drop-in replacement for the GC
>> to do something else.   I could see if being *VERY* useful to make the
>> GC take a compile-time parameter to select which GC engine is used.

>   ur right I never thought of that, I bet all them game devs never 
> thought of it either, they so dumb.  I bet they never tried to use a 
> GC, what fools!  Endless graphs of traced objects, oh yes oh yes!  It 
> only runs when I allocate, oh what a fool I've been, please castigate 
> me harder!
> 
>   Adam pls tell me more of this c# and that amazing gc it sounds so good


First of all, bottom quoting is evil.  Second of all, your response is 
immature.  Thirdly, I am not adam.  And fourthly, I specifically 
mention that many games are currently using garbage collection.

-S.