custom memory management
Simon Bürger" <simon.buerger at rwth-aachen.de>
Simon Bürger" <simon.buerger at rwth-aachen.de>
Fri Feb 28 04:36:47 PST 2014
On Friday, 28 February 2014 at 10:40:17 UTC, Dicebot wrote:
> On Thursday, 27 February 2014 at 21:46:17 UTC, Simon Bürger
> wrote:
>> Sadly, this is incorrect as well. Because if such an object is
>> collected by the gc, but the gc decides not to run the
>> destructor, the buffer will never be free'd.
>
> I think you misiterpret the spec. If object is collected,
> destructor is guaranteed to run. But not all objects are
> guaranteed to be collected. For example, no collection happens
> at program termination.
>
> So it is OK to release resources in destructor that will be
> reclaimed by OS at program termination anyway. List of such
> resources is OS-specific but heap memory tends to be there.
If you are right that would mean that the current dmd/runtime
does not follow the spec. Curious. The current implementation is
not aware of strcut-destructors on the heap, i.e. the
GC.BlkAttr.FINALIZE flag is not set for structs (or arrays of
structs).
In the struct-inside-a-class example, the struct destructor is
called by the (automatically generated) class-destructor. The gc
only knows about class-destrcutor and calls only that one
directly.
More information about the Digitalmars-d-learn
mailing list