On 11/5/14 2:05 PM, Patrick Jeeves wrote:
On Wednesday, 5 November 2014 at 18:56:08 UTC, luminousone wrote:
unless delete is explicitly called, I don't believe the destructor
would ever be called, it would still have a reference in the static
foo_list object that would stop it from being collected by the gc.
Allocate the list with stdc.malloc. It won't be tracked by the GC.
However, note that such accesses need to be synchronized, because the GC
can run in any thread, and be sure that list is shared or __gshared.
Now, another problem with making it untracked by the GC, you need a list
object with a custom allocator. Which I don't think we have yet, you'd
likely have to invent this too.
This is exactly why I asked about it, and even if delete is explicitly
called-- which i believe is deprecated, wouldn't the runtime fill the
space with the default construtor until the GC decides to remove it?
meaning it would be immediatly added back into the list?
This was never the case. The runtime is guaranteed to call the
destructor only once. In order to do this, when the object is finalized,
it's vtable pointer is nulled. So it effectively becomes unusable. This
is the same thing for destroy.
BTW, be very very careful with destructors. They should ONLY be used to
manage NON-GC resources. In this example, if you C malloc the list, you
can access it in the dtor.
-Steve
