Re: Why ABC's make bad Interfaces

From: Peter Ammon (gershwin_at_splintermac.com)
Date: 04/21/04 

Date: Wed, 21 Apr 2004 14:55:16 -0700

christopher diggins wrote:

> The following is from an article I placed on the HeronFront web site (
> http://www.heron-language.com/heronfront.html ) which attempts to explain
> the differences between Abstract Base Classes (ABC) and Interfaces :
>
> --
> Many programmer's make the mistake of assuming that an interface is
> equivalent to an Abstract Base Class (ABC). This is an easy mistake to make
> because it is common practice to implement an interface using ABC's.
> An ABC provides virtual functions that are overridden in the inheriting
> class, which in many object oriented programing language (OOPL)
> implementations means that each instance of the implementing (inheriting)
> class requires a new vtable for each inherited ABC.
>
> The problem with the ABC approach is that we have code bloat within objects
> because of each vtable. Our objects can rapidly become too big and slow due
> to all of the neccessary vtables and lookups.

Certainly, but your approach bloats other objects. It's about tradeoffs
(isn't it always, though?)

> In contrast with ABC's, when we talk of a class implementing an interface,
> we know that there will only ever be one implementation function for each
> method so there is no reason for a vtable.

Sorry, I don't follow this at all. What's the point of an interface if
you only implement it once?

> In order to refer to an object by
> its interface without knowing its type we can do this with "fat" pointer
> made up of two pointers, one to the object instance and another to a static
> interface function lookup table.

Ay, there's the rub.

Here's what I gleaned from looking at the code on your site; please tell
me if I make any mistakes.

For every interface, you create a dummy class that has, as instance
variables, pointers to class functions. For every class that implements
the interface, you store a static pointer to an instance of the dummy
class. To convert an object to its interface, you return a fat pointer
containing a pointer to the object and a pointer to your dummy class.
To call a method from the interface, you invoke the corresponding method
on the dummy class, which uses the class function pointer it stores to
invoke the real method.

This seems very much like a vtable to me. In particular, you're still
invoking a pointer to a class function, which is the main performance
killer. Once I remove the calls to other virtual functions from within
NaiveInt, and hoist the constructors out of the loop bodies, it beats
your HeronFront Int on pointer method invoking by ~ 10%. That is, your
implementation is ~ 10% slower than using ABCs for invoking a method,
and the speed hit comes from the overhead of extracting the data from
the fat pointer and putting it in the right place. This isn't suprising.

Looks like your test showed HeronFront's mechanism to be faster for two
reasons:

1) You were invoking a virtual ToOrdinal() in NaiveInt, but not in Int
2) The NaiveInt constructor has to set up the vtables, which is somewhat
expensive, and you performed this every loop iteration.

I don't mean to imply that your results are invalid, just that calling
it "PointerTimings" is somewhat misleading since you aren't really
measuring the time to call a method through a pointer.

I think your mechanism could be useful to fill a C++ gap, the lack of an
equivalent to the final keyword. That is, a function that's virtual in
a base class is virtual in all derived classes.

-Peter 

-- 
Pull out a splinter to reply.

Relevant Pages

  • Re: C# DLL mittels COM-Interop aus C aufrufen
    ... Have u tried the IDispatch interface, which is used for those language ... which doesnot have capability of maintaining VTables. ... The __cplusplus symbol is defined automatically when you're compiling C ... appropriate function pointer type. ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: Why ABCs make bad Interfaces
    ... >equivalent to an Abstract Base Class. ... >because it is common practice to implement an interface using ABC's. ... >class requires a new vtable for each inherited ABC. ... >to all of the neccessary vtables and lookups. ...
    (comp.object)
  • Why ABCs make bad Interfaces
    ... the differences between Abstract Base Classes (ABC) and Interfaces: ... because it is common practice to implement an interface using ABC's. ... to all of the neccessary vtables and lookups. ...
    (comp.object)
  • Re: Why ABCs make bad Interfaces
    ... >>>because it is common practice to implement an interface using ABC's. ... >>>An ABC provides virtual functions that are overridden in the inheriting ... Rather there is one vtable for>> each class, and each vtable is a union of all its base class vtables. ... >> pointer per fat pointer instead of one vtable pointer per object. ...
    (comp.object)
  • Re: Why ABCs make bad Interfaces
    ... > memory used by the vtables becomes an issue? ... >> mistakenly specifying the interface functions as being virtual, ... This is why an ABC is not an Interfaces. ... Christopher Diggins ...
    (comp.object)