core.exception.InvalidMemoryOperationError@(0)

[ketmar via Digitalmars-d-learn]

On Mon, 26 Jan 2015 05:25:48 +0000, Bayan Rafeh wrote:

> There are 2 problems here:
> 
> 1. By definition, after the destructor is called the object state is
> destroyed. It makes no sense to check the invariant after the destructor
> is called because there is no state for us to check.
i agree that calling invariant after destruction is invalid. i believe 
that this is a bug.

> 2. Invariants theoretically describe the legal states the object can be
> in which includes variables that are GC managed, therefore I should be
> able to check the invariant on GC managed objects as well. What's the
> point of having this feature if I can't even check the invariants of a
> simple data structure like a set, let alone classes involving files?
checking something that is not owned by an object is invalid. invariants 
MUST NOT be dependent on external data or system state. invariants that 
tries to check for GC objects ARE dependent of external state. let alone 
invariants that checking for files, which can be removed while the object 
is still alive.

object can own another object, but it can't own another object *state*.

if you want to check something that involves checking something like 
that, you should use `assert()`s in function body and/or in/out function 
parts.

you are trying to use invariants for the things that invariants can't 
(and must not) check. invariants are meant for checking *internal* 
*object* *consistency*. NOT correctness. NOT applicability. ONLY 
consistency. object can be in "inapplicable" state, but still consistent.
-------------- 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/20150126/87d64c29/attachment-0001.sig>