Skip to main content
GameDev.net gamedev.net
🔒 Locked

Multi inheritance and pure virtual

Started by monkeyboi Jan 27, 2013 at 4:43 PM 3 replies 1.4k views
Original Post
monkeyboi
monkeyboi

Hi I have some question about multi inheritance see the code snippet below



class Window{
public:
	virtual void drawBorder() = 0;
	virtual void prompt() =0;
};

class BorderedWindow:public virtual Window{
public:
	void drawBorder(){}
};

class WindowWithMenu : public virtual Window{
public:
	void prompt(){}
};

class CustomWindow : public BorderedWindow, public WindowWithMenu{
public:
	void draw(){drawBorder(); prompt();}
};

My questions are

  1. why does derived class not have to implement all pure virtual functions declared in base class? Because it is virtual inheritance?
  2. Is :public virtual Window different from :virtual public Window?
wintertime
wintertime
1. That has nothing to do with virtual inheritance. Its to leave the possibility open that programmers make a class hierarchy with more than 2 steps where they continuously add common functionality first and later more specialized. If you try to make a BorderedWindow or WindowWithMenu you will see the compiler guards against this because its an abstract class like Window.
2. Should be the same if it both compiles.

Btw., you should always add a virtual destructor to any baseclass with a virtual method to prevent errors when you only have a pointer or reference to a baseclass which you initialized with an object of the derived class.
SiCrane
SiCrane
In this case BorderedWindow::drawBorder() dominates WindowWithMenu::drawBorder() in CustomWindow and likewise WindowWithMenu::prompt() dominates BorderedWindow::prompt(). Since the dominant member functions are all non-pure virtual the CustomWindow is non-abstract.

Btw., you should always add a virtual destructor to any baseclass with a virtual method to prevent errors when you only have a pointer or reference to a baseclass which you initialized with an object of the derived class.

Note that this isn't necessary in C++11 anymore, as it makes the destructor implicitly virtual if a class has any virtual functions.
EWClay
EWClay


In this case BorderedWindow::drawBorder() C++)>dominates WindowWithMenu::drawBorder() in CustomWindow and likewise WindowWithMenu::prompt() dominates BorderedWindow::prompt(). Since the dominant member functions are all non-pure virtual the CustomWindow is non-abstract.

Btw., you should always add a virtual destructor to any baseclass with a virtual method to prevent errors when you only have a pointer or reference to a baseclass which you initialized with an object of the derived class.

Note that this isn't necessary in C++11 anymore, as it makes the destructor implicitly virtual if a class has any virtual functions.
I can't find anything to back that up, and Visual Studio 2012 does not do it.

At the very least, it seems like a dangerous assumption, and could actually be wrong.
monkeyboi
monkeyboi

1. That has nothing to do with virtual inheritance. Its to leave the possibility open that programmers make a class hierarchy with more than 2 steps where they continuously add common functionality first and later more specialized. If you try to make a BorderedWindow or WindowWithMenu you will see the compiler guards against this because its an abstract class like Window.
2. Should be the same if it both compiles.

Btw., you should always add a virtual destructor to any baseclass with a virtual method to prevent errors when you only have a pointer or reference to a baseclass which you initialized with an object of the derived class.

ok so for pure virtual functions, you dont necessarily have to implement the pure function in the NEXT level derived class. As long as in the hierarchy, derived class(that could be instantiated) has implemented all pure virtual functions from his "higher level base classes" no matter how many levels it derives?

That code was just for demostrating the problem. Thanks for heads up tho.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.