On Wed, 30 Apr 2014 14:00:31 -0700 Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 4/30/14, 1:57 PM, Timon Gehr wrote: > > On 04/30/2014 10:45 PM, Andrei Alexandrescu wrote: > >>> > >>> An extreme one indeed, it would break a lot of my code. Every D > >>> project I wrote that does networking manages memory using a class > >>> that resides on the managed heap, but holds the actual wrapped > >>> data in the unmanaged heap. > >> > >> So should I take it those classes all have destructors? -- Andrei > > > > (Yes, those destructors free the unmanaged memory.) > > Thanks... that would need to change :o). -- Andrei And it doesn't even work now, because it's not guaranteed that finalizers get run. And IIRC, based on some of the discussions at dconf last year, dealing with the GC and unloading shared libraries would probably make the situation even worse. But not being able to rely on finalizers running does put us in a bit of a pickle, because it basically means that any case where you need a finalizer, you should probably be using reference counting rather than the GC. That would tend to mean that either classes are going to need to be wrapped in a struct that reference-counts them and/or they're going to need to be allocated with a custom allocator rather than the GC. This problem makes me think of C#'s using blocks where the object is created at the beginning of the using block, and it's dispose method is called when that block is exited (it may also be collected then, but I don't remember). I don't think that that's quite what we want, since there are plenty of cases where you want to pass a class around, so some kind of reference counting would be better, but we probably should consider having some kind of standard function similar to dispose so that there's a standard method to call when a class needs to be cleaned up. And that could tie into a struct in Phobos that we would have to do the reference counting by wrapping the class. - Jonathan M Davis
