[Optimization] Speculatively not calling invariant on class objects

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Thu Aug 13 11:25:49 PDT 2015


On 13 August 2015 at 20:03, Steven Schveighoffer via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 8/13/15 1:39 PM, Iain Buclaw via Digitalmars-d wrote:
>
>> On 13 August 2015 at 19:12, Steven Schveighoffer via Digitalmars-d
>>
>
>     You could probably get rid of calls to _d_invariant by just calling
>>     the invariant directly, no?
>>
>>
>>
>> Not with classes, because you need to walk over all interfaces in the
>> vtable, which more likely than not is unknown at compile-time.
>>
>
> I guess my understanding of the vtable population isn't very good.
>
> 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.
>
>
class A { invariant { } }
class B : A { }
class C : B { invariant { } }

B b = new C();  // We can only discover that 'b' is a C object at runtime.



> I thought invariant was like ctor/dtor, the most derived automatically
> calls the base version.
>
>
Nope, it only calls it's own invariants.  Calling all derived invariants is
what _d_invariant is for.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150813/437c1b13/attachment.html>


More information about the Digitalmars-d mailing list