<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 13 August 2015 at 20:03, Steven Schveighoffer via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 8/13/15 1:39 PM, Iain Buclaw via Digitalmars-d wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 13 August 2015 at 19:12, Steven Schveighoffer via Digitalmars-d<br>
</blockquote>
<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
    You could probably get rid of calls to _d_invariant by just calling<br>
    the invariant directly, no?<br>
<br>
<br>
<br></span><span class="">
Not with classes, because you need to walk over all interfaces in the<br>
vtable, which more likely than not is unknown at compile-time.<br>
</span></blockquote>
<br>
I guess my understanding of the vtable population isn't very good.<br>
<br>
I thought there was one invariant entry, period. I don't understand why you'd have multiple invariants in an object that you have to cycle through, why wouldn't the fully derived object know how to call them (from one entry point)? Surely, it knows the interfaces it uses.<br>
<br></blockquote><div><br></div><div>class A { invariant { } }<br></div><div>class B : A { }<br></div><div>class C : B { invariant { } }<br><br>B b = new C();  // We can only discover that 'b' is a C object at runtime.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I thought invariant was like ctor/dtor, the most derived automatically calls the base version.<br>
<br></blockquote><div><br></div><div>Nope, it only calls it's own invariants.  Calling all derived invariants is what _d_invariant is for.<br></div></div></div></div>