Smart pointers instead of GC?

[Manu]

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140201/f3f9cb9b/attachment.html>