On Monday, 10 November 2014 at 14:19:26 UTC, Steven Schveighoffer
wrote:
Is the resource a GC resource? If so, don't worry about it.
I might be wrong but my view is that in presence of a GC and
undre the abstraction of R Chen, it is wrong to think about
memory as being a resource anymore.
If the abstraction is that of a machine with infinite memory,
then the very mechanism of freeing memory shall be abstracted for.
This asks for decoupling the memory management of the management
of the other resources and, in particular, RAII-like management.
The management of memory and any other resources is pretty much
identical under C++ since they share the same paradigm. In GC
languages, this is no longer the case.
So, the real question (that will also cover destructors throwing
exceptions and so on) is not what is allowed inside a destructor
(aka finalizer) but *what is allowed in a constructor* of a
GC-managed object.
Since for symmetry purposes the destructor should undo what the
constructor did, this cuts the problem as follows:
1) in GC-entities, the destructor should not deal with releasing
memory. Not only this job is no longer his, but *there is no need
for this kind of job*. Memory is infinite.
2) from symmetry, the constructor should not allocate memory as
it would care about its lifetime.
3) the question in that case is how the other resources are
managed?
3a) If they are to be released in the destructor, then the
destructor's job should be only this (no memory dealloc). In this
case, the resources should be taken in the constructor.
3b) if the destructor disappears completely, then the place to
acquire resources is no longer in the constructor anymore, since
those will never be released.
Ideally, a transparent mechanism to allocate memory would be
needed, without explicit allocation. In this case, the symmetry
would be conserved: the constructor will only acqire resources
(but not memory!) and those resources are released,
symmetrically, in the destructor, at the end of the lifetime.
