On Thursday, 30 January 2014 at 17:11:24 UTC, Steven
Schveighoffer wrote:
On Thu, 30 Jan 2014 11:58:15 -0500, Frustrated
<c1514...@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)
