On Sunday, 20 September 2015 at 18:39:57 UTC, Adam D. Ruppe wrote:
On Sunday, 20 September 2015 at 18:34:37 UTC, Lambert Duijst
wrote:
Oh that surprises me a bit, because I read in the list of
deprecated features that delete is deprecated and that the
right thing to do is to use destroy instead.
Right. One of the benefits of destroy is that it nulls the
reference. Once you destroy it, you aren't supposed to use it
again*. The zombie is kept around until the GC reaps it to
protect against dangling pointers (somewhat), but you still
aren't actually supposed to reuse it.
* If you really want to you can cheat by making a separate
local variable to hold it before destroy it... destroy only
nulls the variable you pass in, but I do not recommend doing
this. Instead, you should reconstruct the object, even if
implementing an object pool or something.
I use writeln("Address of s ", &s) to print the address, not
sure if that is correct though.
that gives you the address of the local variable, not the
reference. For address of the reference, try `cast(void*) s`.
An Object in D is like an Object* in C++. So when you & it, you
get a pointer to a pointer.
Ah, that clarifies a lot ! Thanks. Also does destroy set all
references to that object to null in this case there was only 1,
but in a real program there can of course be many references to
an object.
I wasn't interested in reusing an object after it was deleted,
but more in the behaviour of a program if you do use it after a
deletion. Just want to know if D protects against dangling
pointers or is this just something you should never do.
If we are not supposed to use Object.destroy anymore then how can
we still free non-memory resources that are held by classes
(which are typically cg'ed) in a deterministic way ?
