core.exception.InvalidMemoryOperationError@(0)
ketmar via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Sun Jan 25 16:29:30 PST 2015
On Sun, 25 Jan 2015 22:06:26 +0000, Bayan Rafeh wrote:
> This is another problematic example program:
> import std.stdio;
>
> void main(){
> auto a = new A("/tmp/invalid");
> }
>
> class A {
> File f;
> string path;
>
> this(string path) {
> this.path = path;
> // f = File(path, "r");
> }
>
> invariant() {
> File test = File(path, "r");
> }
> }
>
> is invariant() called during the destruction phase?
the thing is that your invariant is not a correct invariant at all.
invariants are meant to check *internal* object consistency, not external
conditions. compiler is free to call invariant block at any time after
object is properly initialised (i.e. after ctor is complete) and is not
executing member method. so it's perfectly legal to call invariant before
dtor, as you should not check anything that is not belonging to the
object itself in in.
in other words: you can't check any contents of any reference-typed
variables in your invariant block. `string` is reference-typed (it's a
dynamic array managed by GC in your case), so you can't check it contents
in invariant. you CAN, however, use `f` methods in your invariant, as `f`
is a struct which lives *inside* your object, and not a reference var.
but note that it's a bad practice anyway, as some struct can use some GC-
managed objects which can't be safely used in invariant block.
-------------- 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/ef54e330/attachment.sig>
More information about the Digitalmars-d-learn
mailing list