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