Clemens Szyperski in his book "Component Software" (p. 96) succinctly summarized the problem as consisting of:
1. Implementation Inheritance (subclassing)
2. Interface Inheritance (subtyping)

Interface Inheritance obviously avoids the whitebox "diamond problem" issues with Implementation Inheritance, but still shares general inheritance issues of name clashes between superclasses that contain an identical method name.

I find this formal distinction highly useful and precise. Java actually *does* have multiple inheritance - rather than being implementation inheritance it is interface inheritance. C++ does not have a clear distinction between interface and inheritance.

I think that there maybe more to the apparent lack of interest in interfaces in the C++ community than Scott describes.

In C++, the style of interface programming used in Java (and C#) is generally less used (less useful?). Templates are typcally used instead.

As I understand it, interfaces are a formal statement of 'capability' or of conformance to a particular design idiom. For example, in C# the IComparable interface (Comparable in Java, I think) is used to specify that a class can be ordered.

In C++ you would be unlikely to write code using this approach. Instead you would typically use a templated method that relies either on a class's < operator for 'natural' ordering or on some functor object to provide custom ordering. (The std::sort algorithm provides an obvious example).

Looks like another good interview with one of programming's 'movers and shakers' but please, make sure you spell out all the abbreviations the first time that you use them. Here in the UK, an ISA is a common financial instrument. I had to look up its programming context to properly follow the interview.

Vince.

There is a seldom-mentioned difference between data-less, abstract base classes (ABC in C++ or Java) and Java interfaces.

If I inherit an ABC my decendents or I must implement its methods. Not so if I inherit an interface. Implementations may be supplied by my ancestors as well as my decendents.

Given this, I find it useful to think of adding and interface to a class as "tagging" or "describing" rather than "inheritance", "specialisation" or "extension".

The flavour is brought out when you consider that in Java one can non-intrusively tag an existing implementation, C, with an new interface, I, by creating a class that extends C and implements I. No delegation required.

There is a seldom-mentioned difference between data-less, abstract base classes (ABC in C++ or Java) and Java interfaces.

If I inherit an ABC my decendents or I must implement its methods. Not so if I inherit an interface. Implementations may be supplied by my ancestors as well as my decendents.

Given this, I find it useful to think of adding and interface to a class as "tagging" or "describing" rather than "inheritance", "specialisation" or "extension".

You could say this is just part of Java'a solution to the diamond-shaped inheritance problem. But the real flavour is brought out when you consider that in Java one can non-intrusively tag an existing implementation, C, with an new interface, I, by creating a class that extends C and implements I. No delegation required.

I've found small utility classes useful with multiple inheritance in C++. An example of an untility class I'll inherite from even if a class already has a base is my compare helper class:



template<class DERIVED, class COMPARED = DERIVED>
struct CompareHelper
{
bool operator ==(const COMPARED &d2) const
{
return (static_cast<const DERIVED *>(this)->Compare(d2))==0;
}
bool operator >=(const COMPARED &d2) const
{
return (static_cast<const DERIVED *>(this)->Compare(d2))>=0;
}
bool operator <=(const COMPARED &d2) const
{
return (static_cast<const DERIVED *>(this)->Compare(d2))<=0;
}
bool operator !=(const COMPARED &d2) const
{
return !((*this) == d2);
}
bool operator <(const COMPARED &d2) const
{
return !((*this) >= d2);
}
bool operator >(const COMPARED &d2) const
{
return !((*this) <= d2);
}
};


I'll then inherite from this class for each type I want to overload the standard compare operators for.



class my_class
// get compare operators for my class
: public CompareHelper<my_class>
// get compare operators for long type
, public CompareHelper<my_class, long>
{
//<<Define privte here...>>
public:
//<<Define rest of public here...>>

int Compare(const my_class &rhs) const;
int Compare(long rhs) const;
};

int main()
{
my_class c1;
my_class c2;
long l = 9;

if(c1 > c2)
{
//Put greater then code here...
}

if(c1 == l)
{
//Put equal to code here...
}

return 0;

}


Note: the compare helper class is not an ABC. This is to avoid the overhead of the virtual call to Compare().

There is one problem I run into repeatedly in trying to use the Java
interface paradigm in C++.

A C++ class with only pure virtual member functions and no data
doesn't behave at all like a Java interface in at least one important
aspect.

Perhaps an example will explain it best. First I create a C++ style
"interface" class A. Then I create an implementation of A called
AImpl.

class A {
public:
void function1() = 0;
void function2() = 0;
};

class AImpl : public A {
public:
void function1() {// Do something}
void function2() {// Do something}
};


Now I would like to add some functionality to A with a new "interface"
B. I also naturally want to reuse the code I wrote in AImpl. In Java
this is no problem. I just make B extend A then create a new class
BImpl which extends AImpl and implements B. Java doesn't care that
there is an A in the inheritance tree above both B and AImpl. C++
does.

If I make BImpl inherit from both B and AImpl then I have two copies
of A instead of one. A has no data so there is not a big storage
cost, but it is now ambiguous which version of A I am calling through
B as implemented by BImpl.


class B : public A {
public:
void function3() = 0;
};

// In Java this would be 'extend AImpl implement B'
class BImpl : public AImpl, public B {
public:
void function3() {// Do something}
};


Wouldn't it be wonderful if the C++ compiler would realize that one
version of A is still pure virtual and not implemented and the other
version is the implementation? Java does this automatically.


int main(int argc, char *argv[]) {
B *b = new BImpl();

b->function1(); // This is ambiguous.
b->function2(); // This is ambiguous.
b->function3(); // This is of course not!

return 0;
}


Of course I can just map my BImpl functions down to AImpl but this is
a lot of extra typing and if I where to change A I would have to
update BImpl aswell! We then miss the whole point of inheritance.


// An example of mapping BImpl up to AImpl
class BImpl : public AImpl, public B {
public:
void function1() {AImpl::function1();}
void function2() {AImpl::function2();}
void function3() {// Do something}
};


With out this feature is seems that C++ will never be able to fully
reap the benefits of Java interfaces. Maybe one day the standards
committee will be able to wade through all the bureaucracy and add
a 'interface' keyword to C++.

Joseph Coffland

Funny how things work. Minutes after I posted the message above I found a solution to my problem. If you use virtual inheritance whenever inheriting from a C++ style "interface" you no longer have the problem! There is a good explanation of how to use virtual inheritance here: http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.9

Joseph Coffland