Smart pointers instead of GC?

[Manu]

On 4 February 2014 13:31, Manu <turkeyman at gmail.com> wrote:

> On 4 February 2014 12:57, Andrei Alexandrescu <
> SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 2/3/14, 5:36 PM, Adam Wilson wrote:
>>
>>> You still haven't dealt with the cyclic reference problem in ARC. There
>>> is absolutely no way ARC can handle that without programmer input,
>>> therefore, it is simply not possible to switch D to ARC without adding
>>> some language support to deal with cyclic-refs. Ergo, it is simply not
>>> possible to seamlessly switch D to ARC without creating all kinds of
>>> havoc as people now how memory leaks where they didn't before. In order
>>> to support ARC the D language will necessarily have to grow/change to
>>> accommodate it. Apple devs constantly have trouble with cyclic-refs to
>>> this day.
>>>
>>
>> The stock response: weak pointers. But I think the best solution is to
>> allow some form of automatic reference counting backed up by the GC, which
>> will lift cycles.
>
>
> I agree, I suggested that a few times, and Adam ignored it each time.
> With this approach, performance/aggressive users would be able to disable
> the backing GC, and deal with cycles manually, taking responsibility for
> leaking themselves.
> All other users would be able to ignore the problem and have it collected
> by the backing GC, business as usual.
>
> The advantage here is *choice*. Users would then have a fully automated
> system and/or have quite articulate control over it's influence on their
> app.
>

Oh yeah, and the important detail, that it would apply to phobos and other
libraries.
The massive generally un-discussed problem here, is that libraries will
almost always use whatever is default and/or most convenient. I have no
control over the library code I link; if I can't influence the memory
collection routine running behind libraries I'm using, there's a good
chance I simply can't use that library.

I tend to think if we had a GC backed ARC system, then phobos would be
required to support 'gc-disabled' usage, ie, handle weak references
internally (I don't think this is too much to ask for the standard
library), making it useful to the 'gc-disabled' crowd, but the GC would
remain collecting cycles and such for all the regular D users, who don't
want to worry about such troubles. I think the majority of library authors
would then follow the phobos standard of handling weak references manually,
which would result in those libraries not being excluded from realtime use.

The majority of trivial allocations don't produce cycles; closures,
strings, temporary arrays and working sets. These are the allocations that
do occur regularly. Major allocations of complex runtime data that may
contain cycles don't happen at runtime in realtime apps, but these little
trivial/temporary allocations do (and should). Since that sort of transient
data doesn't run the risk of cycles, then it will reliably clean up
quickly, safely, and immediately under ARC, even with backing GC disabled.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140204/c097b32b/attachment.html>