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