Interfaces allow member definitions?

Frustrated c1514843 at drdrb.com
Thu Jan 30 09:30:04 PST 2014


On Thursday, 30 January 2014 at 17:11:24 UTC, Steven
Schveighoffer wrote:
> On Thu, 30 Jan 2014 11:58:15 -0500, Frustrated 
> <c1514843 at drdrb.com> wrote:
>
>
>> Essentially what it boils down to is treating interfaces like
>> classes that have no fields). To avoid the diamond problem 
>> simply
>> always choose the method that is not from the interface(since 
>> it
>> is "default"), which is done naturally with the vtable.
>
> It's simpler than that. A function is a block of code. A vtable 
> entry points to a block of code. Just point the vtable entry at 
> the block of code that is the default implementation.
>
> -Steve

Right, this was my original point and why I thought there was
already entries for the interface in the vtable(since I seemed to
have called some function that did nothing when it should have).

It seems so simple and offers some benefit(would at the very
least stop requiring one to implement a class every time they
want test a design. When programming to interfaces and using some
type of factory it makes even more sense.

It then could also be used to test is something is
implemented(possibly for versioning).

e.g.,

interface A
{
     void hasSomeFeature() { assert(0, "Not implemented yet"); }
}

Someone can come along and implement the feature and you(the
interface) knows it's implemented if it doesn't assert, set a
flag, or whatever.

Are you 100% sure no default space is created for the vtable?
(trying to reconcile why that case I mentioned worked. I'll try
to throw an example up... may have just been coincidence I didn't
get a segfault)


More information about the Digitalmars-d-learn mailing list