On Tuesday, 11 November 2014 at 22:31:17 UTC, Maxime
Chevalier-Boisvert wrote:
I've made it so they unregister themselves in their destructor.
... However, this only works if I can assume that the GC will
first call the destructor on an object, then free the object,
that this is done in a
On Wednesday, 12 November 2014 at 04:06:11 UTC, Algo wrote:
Could this work?
class VM {
static List[VM*] _gcRootLists;
List* gcRootList;
~this() {
_gcRootLists.remove(this);
No. Hash-table operations may try to allocate or free memory
which is not allowed during a GC
With GC you usually have two destructors: one for managed
resources and one for unmanaged resources. Destructor for managed
resources should be run on live objects as soon as you don't need
the resource, it calls unmanaged destructor too. Unmanaged
destructor (finalizer) is called by GC during
On Wednesday, 12 November 2014 at 14:36:19 UTC, Kagamin wrote:
With GC you usually have two destructors:
Which is why this approach is so cumbersome. At least, in non-GC
you only have just one kind of destructor.
It can work with only managed destructor - that's how it's
usually done. Finalizer only guards against slow resource leak
when you forget to free them.
On Wednesday, 12 November 2014 at 14:42:38 UTC, eles wrote:
Which is why this approach is so cumbersome. At least, in
non-GC you only have just one kind of destructor.
It's not necessarily very cumbersome. Standard library usually
provides necessary integration:
I have a situation where I have a VM (virtual machine) object,
and several GCRoot (garbage collector root objects). The GCRoots
are structs and will register themselves into a linked list
belonging to the VM. I've made it so they unregister themselves
in their destructor. This works perfectly
On Tue, 11 Nov 2014 22:31:17 +
Maxime Chevalier-Boisvert via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
What I want to know is: what
guarantees can I expect from destructor behavior?
destructors *may* be called eventually. or not. in any order. but never
twice.
think
As for guarantees for class destructors - you have hard
guarantees that if memory is reclaimed, destructor was called
before. But no guarantees memory will actually be reclaimed.
There is an issue with structs that are directly allocated on
heap - destructors are never called for those. You will want to
change those into classes for GC to do at least something about
it.
See also this bug report :
https://issues.dlang.org/show_bug.cgi?id=2834
On 11/11/14 5:31 PM, Maxime Chevalier-Boisvert wrote:
I have a situation where I have a VM (virtual machine) object, and
several GCRoot (garbage collector root objects). The GCRoots are structs
and will register themselves into a linked list belonging to the VM.
I've made it so they unregister
On Tuesday, 11 November 2014 at 22:31:17 UTC, Maxime
Chevalier-Boisvert wrote:
I have a situation where I have a VM (virtual machine) object,
and several GCRoot (garbage collector root objects). The
GCRoots are structs and will register themselves into a
linked list belonging to the VM. I've
12 matches
Mail list logo
