GC has a "barbaric" destroyng model, I think

[ketmar via Digitalmars-d-learn]

On Wed, 11 Feb 2015 21:33:59 +0000, Andrey Derzhavin wrote:

> If we are using a DMD realization of destroying of objects, happens the
> following: at the calling the «destroy» method the calling of dtor takes
> place always, and then the object which is being destroyed is
> initialized by the default state. In other words, after calling
> «destroy» method, there is no way of getting an access to the members of
> the object that is being destroyed (it is meant, that the members are
> the references). GC works the same way.
> 	This approach in case of manual calling of «destroy» method has
> predictable and understandable consequences (there is no reasone to use
> the object being destroyed). But if GC performes the destroying of the
> objects, a lot of errors appear at the accessing to the members which
> are references, because some of them have already been destroyed (access
> to the members is realized in dtors). Such situations can be avoided, by
> using «@nogc» keyword. Howewer «@nogc» keyword doesn't protect us from
> using the references in dtors: we can assign some values to the
> refernces, we can have access to some members by the references and
> assign them some values.That is not correct in itself.
> 
> If GC starts destroying some group of the objects, it could be more
> correct, if the calls of dtros are occured of all objects in a group
> before phisical memory releasing. Or GC must call dtors of the objetcts
> only, which noone refers to.

this problem has very easy solition: we should stop calling class dtors 
"destructors", and rename them to "finalizers".

The field is lost
Everything is lost
The black one has fallen from the sky and the towers in ruins lie

when finalizer is called, the battlefield is devastated, dead bodies lies 
everywhere, and so on. don't expect that those dead ones can still talk.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20150211/a7fa0ca5/attachment.sig>