Run-time overhead for multiple inheritance

[mmcgarry.work]

Hi,

I would like to follow Stroustrup's advice of separating an object
interface (abstract class) from an object implementation (concrete
class), See Section 15.2.5 in Stroustrup 3rd Edition.

Specifically, I want to create an abstract base class that defines an
object interface:

class myAbstractClass
{
virtual func1() = 0;
virtual func2() = 0;
virtual func3() = 0;
};

I would then have one or more concrete classes that override these
virtual functions to implement this interface.

class usefulClass
: public myAbstractClass // interface
, protected myImplClass1 // implementation of func1() and func2()
, protected myImpClass2 // implementation of func3()
{
...
};

Essentially usefulClass glues together implementation classes that
fill out the interface defined by the abstract class. I would like to
know how to quantify the run-time overhead for this? Is it greater
then the run-time overhead of just inheriting a single concrete base
class?

Thanks for any help,

Michael

 

[Victor Bazarov]

I would like to follow Stroustrup's advice of separating an object
interface (abstract class) from an object implementation (concrete
class), See Section 15.2.5 in Stroustrup 3rd Edition.

Specifically, I want to create an abstract base class that defines an
object interface:

class myAbstractClass
{
virtual func1() = 0;
virtual func2() = 0;
virtual func3() = 0;
};

I would then have one or more concrete classes that override these
virtual functions to implement this interface.

class usefulClass
, protected myImplClass1 // implementation of func1() and func2()
, protected myImpClass2 // implementation of func3()
{
...
};

Essentially usefulClass glues together implementation classes that
fill out the interface defined by the abstract class. I would like to
know how to quantify the run-time overhead for this? Is it greater
then the run-time overhead of just inheriting a single concrete base
class?

How to quantify, eh? I would say, write two programs, one with MI
and the other without it. They should be identical in any other
respect, of course. Then profile them both. The difference could
then be attributed to MI.

Is it greater than just inheriting, you ask? To answer this question
you need to quantify "just inheriting" and then compare the results
to inheriting from multiple base classes. And since none of that is
really important (nor expected to ever be signifincant enough) for
the development of large systems (the primary purpose of C++, BTW),
you will have wasted your time to find out that such run-time overhead
doesn't exist, it's a rumour probably spread by Visual Basic people.

V

 

[Alf P. Steinbach]

* (e-mail address removed):

I would like to follow Stroustrup's advice of separating an object
interface (abstract class) from an object implementation (concrete
class), See Section 15.2.5 in Stroustrup 3rd Edition.

Specifically, I want to create an abstract base class that defines an
object interface:

class myAbstractClass
{
virtual func1() = 0;
virtual func2() = 0;
virtual func3() = 0;
};

I would then have one or more concrete classes that override these
virtual functions to implement this interface.

class usefulClass
: public myAbstractClass // interface
, protected myImplClass1 // implementation of func1() and func2()
, protected myImpClass2 // implementation of func3()
{
...
};

Essentially usefulClass glues together implementation classes that
fill out the interface defined by the abstract class. I would like to
know how to quantify the run-time overhead for this? Is it greater
then the run-time overhead of just inheriting a single concrete base
class?

The way you write it, using wrapper functions, no, a wrapper has the
same overhead anyway.

Letting the compiler tie the implementations to the interface, i.e.
using virtual inheritance (Java-style implementation inheritance), you
may incur some slight overhead because a diamond inheritance requires
more complicated virtual function address lookup.

To quantify this possible overhead in the second case, measure.

By the way, it's generally not a good idea to split implementations of a
single interface in different classes.

That indicates a design error either for the interface or the
implementation classes or both.

Cheers, & hth.,

- Alf

 

[James Kanze]

* (e-mail address removed):

The standard mixin pattern, in sum. Except that in the
classical idiom 1) the implementation classes would generally
inherit from the interface as well, so virtual inheritance is
called for, and 2) the inheritance of the implementation classes
should be private, not protected.

The way you write it, using wrapper functions, no, a wrapper
has the same overhead anyway.

The way he writes it is probably preferable for simple cases,
but it doesn't always work. Suppose that func1() needs to call
func3() in some cases.

Letting the compiler tie the implementations to the interface, i.e.
using virtual inheritance (Java-style implementation inheritance), you
may incur some slight overhead because a diamond inheritance requires
more complicated virtual function address lookup.

Just a nit: the virtual function address lookup is exactly the
same. There is often a small performance loss because the
calculation of the this pointer is slightly more complicated,
and there is also often a small additional space overhead as
well.

To quantify this possible overhead in the second case, measure.

By the way, it's generally not a good idea to split
implementations of a single interface in different classes.

That indicates a design error either for the interface or the
implementation classes or both.

In a lot of cases, perhaps. There are cases where the mixin
pattern is just the thing, however. It's a natural when the
"customization" can be categorized in several dimensions.