Merging abstract and final methods through multiple inheritance - c++

Question

Consider the following program:
#include <stdio.h>
#include <memory>
using namespace std;
class WheeledVehicle {
public:
virtual void drive() const { printf("Default driving implementation."); }
};
class GroundVehicle : public WheeledVehicle {
public:
void drive() const final { WheeledVehicle::drive(); }
};
class DrivableAssaultMachine {
public:
virtual void drive() const = 0;
void fire_cannon();
};
class FighterJet : public DrivableAssaultMachine {
public:
void fly() const { printf("flying my plane.\n"); }
void drive() const override { fly(); }
};
class Tank : public DrivableAssaultMachine, public GroundVehicle {
};
int main(int argc, char **argv) {
make_shared<Tank>()->drive();
return EXIT_SUCCESS;
}
I would like to make this program compile using only modifications to Tank. If I implement drive, then it contradicts the final declaration in GroundVehicle. If I don't implement it, then Tank is abstract and can't be instantiated. Is there some other way to get Tank's inherited implementation of drive() be recognized in the context of inheriting from DrivableAssaultMachine?
EDIT: Renamed everything to provide a more concrete example.

Answer 1

Conceptual flaw:
class FighterJet could not be derived from DrivableAssaultMachine as
DrivableAssaultMachine is derived from class GroundVehicle.
FighterJet are not GroundVehicles.
You should differentiate GroundVehicles and AirVehicles and add: drive and fly as member functions in those and then derive Tank from the first and FighterJet, from the second.
After the n-th Edit:
You've just took under consideration what I've told you and changed the inheritance structure, braking DrivableAssaultMachine from WheeledVehicle
Final Answers:
If I implement drive(), then it contradicts the final declaration in GroundVehicle.
drive() is redundant in FighterJet(as it has fly() available), removing it from there will allow you to override it in Tank.
The virtual drive in DrivableAssaultMachine has nothing to do with the drive() inherited from WheeledVehicle. So there should be ambiguity when try to override it in Tank, as it has as base classes both DrivableAssaultMachine and indirectly WheeledVehicle.
Note: In general your abstract class should provide basic functionality, for example member function: a virtual move() and then the derived classes should wrap it up(override it) and specialize it to their needs, for example: drive() and fly(). Your only tools to specify visibility and accessibility is via the public, private and protected specifier during the definition and the inheritance.

Answer 2

I solved this by creating a diamond hierarchy and using virtual inheritance. Here is a simplified visualization of my hierarchy from the question:
WheeledVehicle
\
DrivableAssaultMachine GroundVehicle
\ /
Tank
Although my feeling is that the compiler should be able to resolve ambiguities and virtualization here, the fact is that it can't. My solution is to fully connect the diamond and use virtual inheritance:
Drivable
/ \
/ WheeledVehicle
/ /
DrivableAssaultMachine GroundVehicle
\ /
Tank
Here is the final program:
#include <stdio.h>
#include <memory>
using namespace std;
class Drivable {
public:
virtual void drive() const = 0;
};
class WheeledVehicle : public virtual Drivable {
public:
virtual void drive() const override { printf("Default driving implementation.\n"); }
};
class GroundVehicle : public WheeledVehicle {
public:
void drive() const final { WheeledVehicle::drive(); }
};
class DrivableAssaultMachine : public virtual Drivable {
public:
void fire_cannon();
};
class Tank : public DrivableAssaultMachine, public GroundVehicle {
};
int main(int argc, char **argv) {
make_shared<Tank>()->drive();
return EXIT_SUCCESS;
}
In general, the workaround appears to be using simple virtual interfaces near the root of your inheritance tree, and combining or complexifying interfaces as you get toward the leaves.

Answer 3

C++ is not Java.
The inheritance and overriding in C++ has to be more explicit than in Java. (I think C++ is right here.)
In C++, two virtual functions declarations foo (with the same signature) are considered homonyms, distinct, unrelated functions unless one declaration overrides the other.
struct B1 {
virtual void foo();
};
struct B2 {
virtual void foo();
};
struct D : B1, B2 {
void bar();
};
D has two inherited declarations of a member function with the same signature, and unqualified calls to foo() within D::bar() would be ambiguous, but the definition of class D is well formed. There is no problem with having potential ambiguities in C++, only ambiguous calls are disallowed.
This means that you can derive from base classes with unrelated homonyms. You just have to avoid ambiguous calls.
Even when both declarations of foo() come from the same class:
struct B {
virtual void foo();
};
struct Left : B {
};
struct Right : B {
};
struct D : Left, Right {
void bar();
};
Both inherited declarations of B::foo() are simply homonyms: they come from the same class, but they in two distinct base classes. C++ lets you have homonyms. The compiler doesn't believe the functions do the same thing or are related in any way other than having the same name, explicit argument list (the arguments inside parentheses), implicit this argument type (of type Base*), and being declared by the same declaration in the source file!
Of course, there is potential ambiguity: if you try to call foo on a derived object, or try to convert (implicitly, or explicitly with static_cast or a C-style cast) a derived pointer to an ambiguous base class pointer.
[Note: some people call that "diamond inheritance" (although the inheritance graph is a tree not a "diamond"), or "dreaded diamond" (it's only dreaded if you don't understand MI in C++) or "diamond of death" (who died?) or "diamond of end of the world" (now I'm making stuff up, but it's only slightly more over the top than "diamond of death"). Seriously, don't freak out people with a potential ambiguity. --end note]
This means that you can derive from base classes with unrelated derivation of the same non virtual base class. You just have to avoid ambiguous calls and ambiguous conversions. (This can happen when two classes derive from the same utility class like refcounted_base.)
In Java, multiple inheritance of classes doesn't exist, but multiple interface inheritance does, and distinct declarations of a given (pure virtual) function are synonyms:
interface I {
void foo();
}
class Base {
public void foo() { }
}
class Der extends Base implements I {
}
Here Base::foo() will implement I::foo() even if neither Base nor I names or knows about one another. This never happens in C++.
Although my feeling is that the compiler should be able to resolve ambiguities and virtualization here,
Your feeling is based on an incorrect notion of C++ inheritance model; the compiler cannot know your intent. You gave the compiler two different declarations, just because they are homonyms does not mean you intended to have synonyms.
By inheriting from a common interface (with virtual inheritance as you should with interfaces), you are telling the compiler that there is only one feature drive. All uses of drive are synonyms now.