On 13 August 2015 at 19:12, Steven Schveighoffer via Digitalmars-d < [email protected]> wrote:
> On 8/12/15 8:22 AM, Iain Buclaw wrote: > >> This post got me thinking: >> http://forum.dlang.org/post/[email protected] >> >> We know at compile time for a given object whether or not there are any >> invariants, lack of any polymorphism, along with disallowing invariants >> in interfaces means that for the given: >> >> class NoInvariants { } >> NoInvariants obj; >> assert(obj); >> >> It's only a case of checking each base class for any invariant >> functions, and if none are found, then we can make an (almost) >> reasonable assumption that calling _d_invariant will result in nothing >> but wasted cycles. >> >> However, these can't be omitted completely at compile-time given that we >> can't guarantee if there are any up-cast classes that have an invariant. >> >> But we should be able to speculatively test at runtime whether or not a >> call to _d_invariant may be required by doing a simple pointer test on >> the classinfo. >> > > My thought was that you could just set the default invariant pointer to > null. Then when you load the invariant function to call, if it's null, > don't call it. > > That is what's done at compile time with structs. > You could probably get rid of calls to _d_invariant by just calling the > invariant directly, no? > > -Steve > Not with classes, because you need to walk over all interfaces in the vtable, which more likely than not is unknown at compile-time. Regards Iain.
