Multiple Inheritance??

Hi,

The syntax is:
class ChatRoom: public BaseObj, CChatBuffer { ... }

but don''t do it. First of all the compiler has a hard time (lower speed) making sure that it is using the correct vtable at all times (for BaseObj, CChatBuffer), so it gets slower. Furthermore, I have gotten some strange errors when you convert pointers to such classes to void* and back again.

You must ask yourself, is a ChatRoom both a BaseObj and a CChatBuffer? Often they are not. I recommend one of the following approaches:

1. let CChatBuffer inherit from BaseObj and let ChatRoom inherit from CChatBuffer.
2. just inherit from baseObj and add CChatBuffer using composition instead of inheritance.

Jacob Marner

You would probably be better off making BaseObj and CChatBuffer data members of the ChatRoom class, like this:


#include "baseobj.h"
#include "chatbuffer.h"

class ChatRoom
{
private:
BaseObj m_SpriteManager;
CChatBuffer m_Buffer;
};



The only time you really need to use multiple inheritance is to create one object that is made out of several other objects. Here''s an example from the STL:


class ifstream; // file input
class ofstream; // file output

class fstream : public ifstream, public ofstream
{
};



In that example, fstream now has all the capabilities of ifstream and ofstream.

---

- null_pointer
Sabre Multimedia

Hey, thanks a lot guys.
I think I''ll end up inheriting from CChatBuffer and just using an instance of BaseObj.
Thanks again
- Rob

re: not ever using multiple inheritence

Granted, it''s confusing, but it can be very useful. For instance, if you''re writing a library and you have many objects with similar interfaces, it''s helpful to write a pure-virtual interface class and have your classes derive from several of them:

// interface classes class IAttackingUnit { public: virtual int getDamage () = 0; }; class IDefendingUnit { public: virtual int getArmor () = 0; }; class IMovingUnit { public: virtual int getSpeed () = 0; }; // now on to the REAL classes class Turret : public IAttackingUnit, public IDefendingUnit { public: virtual int getDamage (); virtual int getArmor (); }; class FootSoldier : public IAttackingUnit, public IDefendingUnit, public IMovingUnit { public: virtual int getDamage (); virtual int getArmor (); virtual int getSpeed (); };

The advantage of doing this is that you MUST fill-in all of those functions in your derived classes, or you can''t instantiate an object of that class. When your classes get complicated, this can help partition each part of the interface so you know you don''t leave anything out. Also, when you decide to add something to one of the interfaces, it won''t compile until you implement it for each of your derived classes. Cool stuff, eh?

That last post really is just explaining C++''s hackety-tackety way of implementing Java''s "Interfaces".
You can get some really strange errors with multiple inheritance ( specifically when the order matters because you have an implementation of the same virtual function in both base classes. )
It''s probably better to avoid it if at all you can.


Give me one more medicated peaceful moment..
~ (V)^|) |<é!t|-| ~
ERROR: Your beta-version of Life1.0 has expired. Please upgrade to the full version. All important social functions will be disabled from now on.

I see multiple inheritance as a good use for so called mix-in objects. You create small classes that provide a small specific functionality. An instance of just the class is not useful. For another you class, you mix in specific pieces of functionality by inheriting from multiple mixin objects. If you make sure that each mixin provides a different piece of functionality, problems by multiple inheritance can be avoided. It''s a bit like Java interfaces, except that the mixin base object already has some of the methods implemented.

An example of a mixin could be to make an object streamable (with read and write methods), threadable, etc. For more examples, see the CIDLib C++ framework (http://www.charmedquark.com/), which uses mixins.

Erik

Man, MadKeith just has a huge ole chip on his shoulder for me.

In fact, it''s not a hackety explanation--it''s how we design our hardware interface libraries at work. Haven''t had a problem with same-named functions yet (we''re careful with our function names), but virtual inheritence can be used to solve that issue.

Stoffel, I dont think MadKeith was trying to attack what you said. I think you read it wrong as I did at first, but read it again carefully. All he says is that your code snippet shows "C++''s hackety-tackety way of implementing Java''s "Interfaces".

That''s C++''s hackety-tackety way, not yours
I think he''s just burning C++

MadKeith,
Since when have you become a Java prophet ?

joeG

P.S. Very much just kidding, I''ve seen that you''ve been hanging around the Java board lately, that''s all.