On Sunday, March 08, 2015 14:04:52 Timothee Cour via Digitalmars-d-learn wrote: > On Sun, Mar 8, 2015 at 4:36 AM, Jonathan M Davis via Digitalmars-d-learn < > > I would point out though that until recently, the GC never ran the > > destructors for structs on the heap, because it didn't have the type > > information to do it. So, if you did > > > > auto s = new MyStruct; > > > > its destructor never ran, even if the GC collected it (which it's not > > guaranteed to do with any memory). But I don't know if the destructor was > > run if you expliictly called delete on the pointer to the struct. > > > > Thanks for you answers, however this last sentence worries me. According to > it there's no guarantee then?
Previously, struct destructors were _never_ run by the GC, because it didn't have the required type information. What I don't know is whether delete called a struct's destructor or not. But if it didn't, then it never did. There was no maybe about it. Either it always did, or it never did. I just don't know which it is, because I haven't really used delete, and I don't recall anyone discussing whether delete had the same problem that the GC does when it runs (I'd guess not, but I'd have to test it). With the upcoming release, however, it's been changed so that struct destructors _do_ get called by the GC, which would presumably make it so that delete calls the struct's destructor if it didn't before. I guess that I can just revert my dmd to an older release and see what happens there (I'm normally sitting on master)... Yeah. delete calls the struct's destructor even though the GC doesn't. And there's nothing non-deterministic about it. The GC isn't guaranteed to collect something (so even with the recent changes with regards to structs, there's still no guarantee that their destructors will be run), but delete is, since you're explicitly telling it to. It was just a question of whether delete had the same problem that the GC did and couldn't run the struct's destructor. But fortunately, that doesn't seem to be the case. - Jonathan M Davis
