virtual functions

[yman]

Hi!
I have a slightly trickier tree of classes (and I worry it cannot be simpler).
The root class is a simple interface, call it IRoot. It declares a pure virtual function, lets say virtual int foo() = 0;, nothing more.
There is one more interface, IInterface, extending IRoot abstract class by some other pure virtual functions.
Class TRoot implements (extends) IRoot interface and adds a number of new methods. This class therefore is not abstract, the foo() function is implemented.
Then I have a class TDescendent extending both TRoot and IInterface, it does not add a new functionality:

class TDescendent: public TRoot, public IInterface {
}

I would think that everything is ok - the foo() function is declared in an ancestor of both classes (TRoot, IInterface) and in one of them (TRoot) has been implemented.
The reality differs, though. The compiler says that TDescendent is abstract because a pure virtual function foo() is present.

I know a possible solution:

class TDescendent: public TRoot, public IInterface {
virtual int foo() { return TRoot::foo(); }
}

But I do not like that because it seams the TDescendent::foo() function CAN differ from TRoot::foo() (unless everyone can see the body of the function). I would prefere ?SOME? declaration that TDescendent::foo() function IS THE SAME as TRoot::foo(), the best would be if I even would not have to declare it in TDescendent because it was ?SOME WAY? implicit.

Do you understand what I'm trying to solve? Do you have any suggestion?
Thank you in advance,
yman

[R0mai]

Uhhohh, You have the famous diamond inheritance problem.
http://en.wikipedia.org/wiki/Diamond_problem
You'll need virtual inheritance at TRoot and IInterface when inheriting from IRoot.
But I don't think this kind of inheritance model is the simplest solution.

[yman]

Aaaaah, nice!
I did not know the virtual inheritance mechanism, but this solution seems much nicer to me.
Are the disadvantages important? I've read that every descendent of a virtually inherited class is automatically also virtually inherited, and so some additional pointer needs to be kept. Is it an important issue? Does it make the program appreciably slower?

I was thinking about the class hierarchy for a long time, but I consider this solution to be the best, at least in the logical way.

[R0mai]

Does it make the program appreciably slower?

I've never had to use virtual inheritance, but I doubt it has any (noticeable) overhead.

[sohguanh]

This is a classic example of why it is so complicated that Java has scrap multiple inheritance totally. I think in this aspect Java do it the "correct" way. If there is a need for multiple inheritance, we can uses Java interface concept.

I am not a C++ betrayer but I believe Java language do have some good design as in clarity and not allowing friend classes/functions and operator overloading.

[Disch]

have some good design as in clarity and not allowing friend classes/functions and operator overloading.

Removing any of those things does not increase clarity for the people using your code. The only increase it for the person writing the code, and only if they choose to use those aspects.

Just because some people misuse a feature doesn't make the feature bad.

[firedraco]

not allowing friend classes/functions and operator overloading.

Actually this makes the code far more annoying by forcing you to write getter/setter armies for functions that technically should not be accessible by users.

[Disch]

yeah.

Not to mention operator overloading (when used properly) makes code much more intuitive and easy to follow.

[sohguanh]

The problem with friend classes/functions and operator overloading is they are wonderful features but if used inappropriately. it make maintenance difficult and understanding not so intuitive.

E.g
operator overloading used in say a Person will look weird.
Person a;
Person b;

Person c = a + b; // errr.... this is trying to say Person A + Person B gives Person C ? A Person is a human say that model after the business domain and we are saying Person can add to each other or we are trying to say Person A mate with Person B to give birth to Person C ? :P

For friend classes, it takes a practical approach but if your perspective is strictly OOP, then all private variables should be accessed via getter/setters.

I am not saying C++ is more complicated, what I am saying is Java is created long after C++ is created so I believe the Java creators take note of C++ and decide to trim down the language features to more manageable level.

My opinion is C++ have good language features, I can choose to use or NOT to use. For Java they take away so there is only one choice :P

[Disch]

but if used inappropriately. it make maintenance difficult and understanding not so intuitive.

But if used appropriately they make maintenance easier and understanding more intuitive.

Person c = a + b; // errr.... this is trying to say Person A + Person B gives Person C ?

Right... that would be an example of the wrong way to overload an operator. I'm not saying you can't misuse them, I'm saying that just because they can be misused doesn't mean you should remove them from the language.

There's always ways to write bad code in any language. Removing functionality doesn't make it any less likely that the language will be misused.

For friend classes, it takes a practical approach but if your perspective is strictly OOP, then all private variables should be accessed via getter/setters.

I disagree almost entirely with this statement =P

If you want to talk about language features/styles that are commonly misused, getters/setters are a prime example.

[sohguanh]

There's always ways to write bad code in any language. Removing functionality doesn't make it any less likely that the language will be misused.

Hmmm.... I would think the Java creators is against above statement ? Obviously they feel removal will at least cut down a whole set of problem related to that language features ?

A classic example would be C++ * & used interchangeably and in Java * will be strictly for multiplication and & will be bitwise AND. We do not have to consider depend on usage, * could mean pointer & could be reference besides just plain multiplication and bitwise AND etc.

Again, I would like to re-iterate I am not against C++ but I should not write off Java either. I believe Java creators is trying to make life easier for developers.

[Disch]

I don't either one of us can state what the Java creators intended when they were designing the language. Obviously if they did everything the same way C++ does they wouldn't need to go through the trouble of creating another language.

Personally I see the exclusion of these features as shortcomings of the language, as these features (when used properly) can greatly enhance development for everyone involved.

But I'm not trying to say C++ is a superior language or anything like that. I was just rebutting the statement you made earlier that essentially said "Java is doing things the correct way by removing X feature".