Access Violation Tracking

[via Digitalmars-d-learn]

On Sunday, 9 November 2014 at 14:45:11 UTC, ketmar via 
Digitalmars-d-learn wrote:
> On Sun, 09 Nov 2014 09:33:29 -0500
> Etienne via Digitalmars-d-learn 
> <digitalmars-d-learn at puremagic.com>
> wrote:
>
>> I've seen a lot more invalid memory operation errors since the 
>> GC calls destructors. Letting the GC destroy objects out of 
>> order can be the issue. We might have to make an associative 
>> array of static global flags (debug bool[void*]) for each 
>> object to see if it was destroyed, and use asserts in the 
>> destructors / update the associative array, as a new idiom.
> that's where i want precise GC to come into play. i really want 
> it to
> nullify all internal pointers to finalized objects before 
> calling
> destructor. sure, this can modify alot of members, so it must 
> be opt-in
> feature.
>
> ah, and stop calling class finalizers "destructors" helps too. 
> they
> are... well... finalizers, not destructors. ;-)

I once suggested to introduce dedicated finalizers that get 
called instead of the destructor by the GC, and nobody argued 
against it ;-)

They would be applicable to both classes and structs. A finalizer 
may only perform a subset of what's allowed in destructors, and 
the compiler might be able to verify that. For DRYness, the 
finalizer can optionally be called by the destructor, because 
everything that is valid in a finalizer should also be valid in a 
destructor.