GC-proof resource classes

cym13 via Digitalmars-d digitalmars-d at puremagic.com
Sat Aug 29 07:08:07 PDT 2015


On Saturday, 29 August 2015 at 13:58:07 UTC, ponce wrote:
> Example 1:
>
> You forget to release Resource A. The GC happen to call A 
> destructor that releases it. But GC destructors are not 
> guaranteed to happen.
> See http://dlang.org/class.html ("The garbage collector is not 
> guaranteed to run the destructor for all unreferenced objects").

This, ok, it is the common GC flaw that it shouldn't memleak but 
might. To me it isn't either an "accidentally correct design" nor 
an "avoided leak" but ok. If something _has_ to be freed then it 
should be done explicitely either way hence crashing the GC for 
that particular ressource, I follow you here.

> Example 2:
>
> Resource A depends on Resource B. You forget to release either. 
> The GC happens to call A and B destructors in the right order, 
> by chance. A new D release changes this order later.

Here comes the accidentally correct design. Ok, I'm with you on 
that one.

I think however that this should really be limited on ressources 
that _must_ be freed in time. It shouldn't become a standard way 
to deal with the GC.



More information about the Digitalmars-d mailing list