Don't expect class destructors to be called at all by the GC

[H. S. Teoh]

On Sun, Dec 24, 2017 at 02:07:26PM -0700, Jonathan M Davis via Digitalmars-d-learn wrote:
[...]
> Regardless, even if it were the case that it were guaranteed that all
> finalizers were run when the program exited, it would still be
> terrible practice to rely on it. It's trivial to end up in a situation
> where no collection is run for quite some time (e.g. just don't do
> much memory allocation for a while), which would leave any resources
> that needed to be freed by a finalizer unfreed for quite a while even
> though they weren't needed anymore. So practically speaking, it
> doesn't really matter where the finalizers are guaranteed to run.
> Relying on them to be run rather than forcing them to be run via
> destroy or using some other helper function is just going to cause
> problems, so it's just plain bad practice to rely on finalizers to be
> run to release resources. That's just life with GC's in general, not
> just D's. It's why C# has the while dispose/IDisposable thing, and why
> D code should either be using destroy to deal with freeing resources
> for a class or using structs on the stack for resources that need to
> be freed. Or alternate memory strategies can be used via
> std.experimental.allocator. The GC works great for lots of stuff but
> not for system resources. Honestly, in some ways, we'd be better off
> if D didn't even have finalizers.
[...]

This makes me wonder if a better approach to memory management is to use
refcounting by default, and fallback to the GC to collect cycles.

In my current project, I'll probably end up having to use
RefCounted!Database just so I can have deterministic releasing of
database handles without needing to worry about dangling references that
may still be lingering around. (Currently, I'm just calling .destroy
directly on the handle when I'm done with it, but there's a slim
possibility that there might be dangling references left somewhere. So
that needs to be addressed at some point.)


T

-- 
"I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr