Smart pointers instead of GC?

[Adam Wilson]

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.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator