On 7/26/17 8:20 PM, Moritz Maxeiner wrote:
On Thursday, 27 July 2017 at 00:00:08 UTC, Steven Schveighoffer wrote:
On 7/26/17 7:28 PM, Moritz Maxeiner wrote:
On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven Schveighoffer wrote:
On 7/26/17 2:33 PM, Moritz Maxeiner wrote:
A finalizer may freely work on non-pointer members and pointer
members that target objects outside the GC pool which the programmer
knows to be valid at finalization (e.g. they are manually managed).
Whether or not it makes sense for the finalizer to call the
destructor is something the programmer has to decide on a per use
case basis.
No, because a destructor can safely assume it can look at GC members'
data. So a finalizer can never call it.
No, whether a finalizer can safely call a destructor depends on the
destructor's body.
If the destructor doesn't access GC members and doesn't allocate using
the GC, the finalizer can safely call it. That's why it's the
programmer's job to determine this on a use case basis.
I suppose this is true, but in practice, you wouldn't in a destructor
that which is available for a finalizer. In other words, you simply
wouldn't implement such a destructor.
It's also very fragile as the maintainer of the destructor is working
under different assumptions from the finalizer. If you call the
destructor from the finalizer, then the rules of the finalizer infect
the destructor.
-Steve
