Accessing memory after destroy

Johan Engelen via Digitalmars-d digitalmars-d at puremagic.com
Sun Jul 30 00:45:27 PDT 2017


On Saturday, 29 July 2017 at 23:09:38 UTC, Jonathan M Davis wrote:
>>
>> [1] https://dlang.org/spec/class.html#deallocators
>
> If destroy has been called on a class object, then it is a bug 
> to access it at any point after that (IIRC, the expectation is 
> that it will blow up in your face, because the vtable is gone - 
> TDPL talks about this, I believe, but I don't know where my 
> copy is at the moment, so I can't check). That being said, the 
> memory is still valid. And as Moritz pointed out, if the memory 
> is accessible, the GC won't free it. So, it's a bug to access 
> the object, but it should be memory safe to do so.

If this is the case, then we really need to improve and pin-down 
the spec on this point.

So `destroy` only calls the destructor and puts the object in 
`T.initializer` (non-constructed) state, and is otherwise not 
related to memory deallocation.
May the destructor be called again when the GC collects the 
memory?
Why is the object put in `T.initializer` state?

To make sure: My question is from a spec point of view. Not about 
what currently happens and what is "OK" with the current 
implementation.





More information about the Digitalmars-d mailing list