Diamond inheritance =/

[camelCase]

I have something like this:

class Base {
    public:
        virtual void doSomething ();
};

class Derived_Abstract {
    public:
        virtual void doSomething ();
        virtual void abstractStuff () = 0;
};

class Derived {
    public:
        virtual void doSomething ();
};

class OhMyGawdWhatAmIDoing : public Derived_Abstract, public Derived {
    public:
        virtual void doSomething ();
        virtual void abstractStuff () = 0;
};

The problem is class "OhMyGawdWhatAmIDoing" (It, too is abstract).
It implements the pure virtual method and it's doSomething() implementation calls the doSomething() method of both Derived_Abstract and Derived.

The thing is, it'll inherit Derived_Abstract's doSomething() implementation by default (something about dominance; some compiler warning). This generates a warning and I don't like to see warnings =/

My current solution is ugly but it gets rid of the warning:

class OhMyGawdWhatAmIDoing : public Derived_Abstract {
    public:
        virtual void doSomething ();
        virtual void abstractStuff () = 0;
    protected:
        Derived d; //Tadah
};

So, no more diamond inheritance and doSomething() can call the doSomething() method of both classes.
But it seems kinda' ugly, I duno.

Any way around this?

 

[s3rius]

You can call both functions by their qualified names:

class OhMyGawdWhatAmIDoing : public Derived_Abstract, public Derived {
    public:

		void doSomething (){
			Derived::doSomething();  //calls Derived's implementation
			Derived_Abstract::doSomething(); //calls Derived_Abstract's implementation
		};

		void abstractStuff (){};
};

But VS2010 doesn't give me any warnings at /W4.

 

[camelCase]

Strange..
I don't get the dominance issue anymore.

Anyway,
That "OhMyGawdWhatAmIDoing" class is abstract because it's to be inherited from with the derived class implementing abstractStuff().

So, there are, like, multiple classes that derive from "OhMyGawdWhatAmIDoing" and when I have to convert a pointer from "DerivesFromOMG" to "Base", it becomes an ambiguous conversion =/

DerivesFromOMG omg;
Base* base_ptr = &omg;//Ambiguous conversion; can go the route of Derived_Abstract or Derived

Also, "Base" has a non-virtual method that when called from "DerivesFromOMG" is also an ambiguous call =/

I know I can use their qualified names but that I'll have two names that call the same method:
Derived_Abstract::nonVirtualMethod();
Derived::nonVirtualMethod();

 

[s3rius]

Ah, I get it.

You can use virtual inheritance.

However your example code is pretty messed up (no class derives from Base, undeclared functions etc) so I'll mash together a minimal-code example:

class Base {
    public:
		virtual void doSomething (){ /* blub */ };
};

class A : virtual public Base{ //<-- virtual
    public:
		virtual void doSomething () { /* blah */ };
};

class B : virtual public Base{ // <-- virtual
    public:
		virtual void doSomething () = 0;
};

class D : public A, public B { //you can derive from this one as much as you want to
    public:
		virtual void doSomething (){};
};


void main(){
    Base* base_ptr = new D(); // OK
}

 

[camelCase]

This is strange...
I tried virtual inheritance earlier on but had problems but now that you're telling me to do it there isn't any..
I must have done something wrong earlier on =x

Thanks for the help s3rius!

 

[GFreak45]

When you have a class a inheriting from pure virtual class b and implementing its methods (non-virtually), then you have class c inheriting from class a and implementing its own version of all virtual functions from class b it will over-ride the functions from class a. Basically class a does not have to have the virtual modifier for class c to inherit it's functions virtually, and actually should not have the virtual modifier as it actually does nothing at that point unless it is an overloaded function or one that is not inherited.

While this works it is not recommended to use virtual functions in the end result application as they take up extra memory (virtual functions are actually function pointer members that are set based on the class they are created for, allowing pointers to these used as pointer from the base class to still call the derived function), and there are ways around virtual inheritance. They do have their uses (ease of use primarily) but larger applications using virtual functions can be very taxing on ram.

 

[camelCase]

Yes, but I my actual usage at that point in time was for a game state class.

class GameState; <-- Base class
class MenuState; <-- Generic menu state
class StarsState; <-- A state that does nothing more than blit stars onto the screen and have them move
class MainMenuState; <-- Inherits from MenuState and StarsState

And other game state classes could just inherit from only MenuState or only StarsState and not over-ride the functions; so, I had a reason to make them inherit functions from class GameState virtually.

Thanks for the warning on virtuals, though.
I seem to forget that little extra cost every time.

 

[GFreak45]

thats odd... generally you can overload dual inheritance from the same tree, at least iv never run into problems with it
ie:
A class a has the method: void DoAStuff ()
classes b and c inherit from class a
class d inherits from b and c
class d gets DoAStuff directly from a, then checks for overloads in b and c
I believe that the override inherited (if there are 2) would be the first one in the list of inherited classes (ie: class a : public b, public c... would inherit from b im guessing)
also class b and c's overrides can be called directly via:

this->b::DoAStuff()

Now where there might be an issue is if they both have functions named the same thing taking the same parameters, that would cause an error if i am correct, so that should actually be removed and added to class a

 

[camelCase]

Yeah, that works but the syntax isn't so pretty when we have classes with more complex names =x

class Base {
    public:
        void die () {}
};
 
class D1 : public Base {
};
 
class D2 : public Base {
};
 
class Error : public D1, public D2 {
};
 
int main () {
    Error e;
    e.die(); //Error; ambiguous
    return 0;
}

It just seemed ugly to have to qualify the call with a D1 or D2 when both call the same thing.

It isn't a matter of it being possible but which is simply cleaner =/
D1::die() and D2::die() mean the same thing but by allowing the option to choose one or the other, I risk making things confusing and being inconsistent by using D1::die() sometimes and D2::die() at others which was pretty bad (to me).

 

[GFreak45]

you can over-ride the die() function to manage which function it actually calls, so its not ambiguous

class Error : public D1, public D2
{
    void die () { D1::die(); }
}
 
int main ()
{
    Error e;
    e.die(); //No Error, not ambiguous
    return 0;
}

I see no reason for that to be ambiguous when they are actually inheriting the same exact function, that's just bad compiler programming, that should be added into the C++ strictures.

 

[camelCase]

IIRC, inheriting from both D1 and D2 creates two instances of class Base.
So, while D1 and D2 may provide extra functionality, they also have their own instances of class Base.

So, if class Base happens to have an integer "i" and we go:
Error e;
e.i = 5; //Error; also ambiguous

If I followed your suggestion, I'd have to override a lot of stuff if my class is particularly hairy and D1's methods would just operate on it's own Base while D2's methods would also operate on it's own Base.

The virtual inheritance was really all I needed because it creates only one instance; C++'s way of combating the problem, I suppose.