Invariant for default construction

Daniel Murphy via Digitalmars-d digitalmars-d at puremagic.com
Sun Dec 21 23:18:56 PST 2014


"Walter Bright"  wrote in message news:m753hk$pt2$1 at digitalmars.com...

> Invariants should be checking the state of the object that it owns, not 
> other objects. I would consider such an invariant invalid.

What?  No.

This is a perfectly valid use of invariants:

class A
{
    B b;
    invariant()
    {
        assert(!b || b.getA() is this);
    }
}

class B
{
    A a;
    A getA() { return a; }
}

ie checking that the two objects reference each other.  This will fail if B 
is destroyed before A's invariant is run.

I don't see why we'd want anything other than
1. Determine which memory objects are unreferenced
2. Run their invariants
3. Run their destructors

Running the invariants while you're part-way through destroying the object 
graph is just insane. 



More information about the Digitalmars-d mailing list