On Tuesday, 13 May 2014 at 14:59:42 UTC, Kagamin wrote:
On Tuesday, 13 May 2014 at 12:18:06 UTC, Manu via Digitalmars-d
wrote:
It completely undermines the point. If you're prepared to call
finalise, when you might as well call free... Every single
detail
required to perform full manual memory management is required
to use
finalise correctly.
I see absolutely no point in a GC when used with objects that
require
you to manually call finalise anyway.
Well, GC doesn't run immidiately, so you can't do eager
resource management with it. GC manages memory, not other
resources, and lots of people do see point in it: java and C#
are industry quality technologies in wide use.
ARC release is eager. It's extremely common that destructors
either
expect to be called eagerly, or rely on proper destruction
ordering.
Otherwise you end up with finalise again, read: unsafe manual
memory
management :/
No language will figure out all algorithms for you, but this
looks like a rare scenario: for example, kernel objects don't
require ordered destruction.
Finalizer will be called when GC collects the object, it's a
last resort cleanup, but it's not as unsafe as it used to be.
It's not (memory) unsafe because you cannot delete live objects
accidentally, but it's "unsafe" because it leaks resources.
Imagine a file object that relies on the destructor closing the
file descriptor. You will quickly run out of FDs...
I only see two use cases for finalizers (as opposed to
destructors):
1.) Release manually allocated objects (or even ARC objects) that
belong to the finalized object, i.e. releasing dependent objects.
This, of course _must not_ involve critical external resources
like FDs or temporary files.
2.) Implement weak references.
