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