There is an ongoing debate in the C++ and object-oriented communities over the value of multiple inheritance (MI). The Visual C++ compiler and development environment fully support MI.

The MFC class library has been designed so that you do not need to understand MI to use MFC. MI is not used in any of the MFC classes. We have found that MI is not required to write a class library, nor is it required for writing serious applications. To use MI or not can be a personal decision, so we leave that decision to you.

If you already understand how to use MI, understand the performance trade-offs, and want to use MFC, this tech note will tell you what you must do. Some of the restrictions are general C++ restrictions, others are imposed by the MFC architecture.

The following describes some of the technical issues of how MI affects the use of common MFC idioms. At the end of this technical note a complete MFC application using MI is included which you can extract and compile.

The persistence and dynamic object creation mechanisms of MFC use the CRuntimeClass data structure to uniquely identify classes. MFC associates one structure of this type with each dynamic and/or serializable class in the application. These structures are initialized at application startup time using a special static object of type AFX_CLASSINIT. You need not concern yourself with the implementation of this information, as it is likely to change between revisions of MFC.

The current implementation of CRuntimeClass does not support Multiple Inheritance runtime type information. This does not mean you cannot use MI in your MFC application, but if you do, you will have certain responsibilities when working with objects that have more than one base class.

The CObject::IsKindOf member function will not correctly determine the type of an object if it has multiple base classes. Therefore, you cannot use CObject as a virtual base class, and all calls to CObject member functions such as Serialize and operator new will need to have scope qualifiers so that C++ can disambiguate the appropriate function call. If you do find the need to use MI within MFC, then you should be sure to make the class containing the CObject base class the left-most class in the list of base classes.

For advice on the uses and abuses of MI, see Advanced C++ Programming Styles and Idioms by James O. Coplien (Addison Wesley, 1992).

As you know, all significant classes derive directly or indirectly from class CObject. CObject does not have any member data, but does have some default functionality. When using MI, it will be common to inherit from two or more CObject-derived classes, for example, a CFrameWnd and a CObList:

class CListWnd : public CFrameWnd, public CObList
{
 ...
};
CListWnd myListWnd;

In this case CObject is included twice, which leads to two problems:

• Any reference to CObject member functions must be disambiguated.

  myListWnd.Dump(afxDump);
      // compile time error, CFrameWnd::Dump or CObList::Dump ?

• Static member functions, including 'operator new' and 'operator delete' must also be disambiguated.

When creating a new class with two or more CObject derived base classes, reimplement those CObject members that you expect people to use. Operators new and delete are mandatory, and Dump is recommended. For example:

class CListWnd : public CFrameWnd, public CObList
{
public:
    void* operator new(size_t nSize)
        { return CFrameWnd::operator new(nSize); }
    void operator delete(void* p)
        { CFrameWnd::operator delete(p); }

    void Dump(CDumpContent& dc)
        { CFrameWnd::Dump(dc);
          CObList::Dump(dc); }
     ...
};

You may ask, "If you inherit CObject virtually, won't all of the ambiguity problems go away?"

Even in the efficient Microsoft Object Model, virtual inheritance is not as efficient as nonvirtual inheritance (just as Multiple Inheritance is not as efficient as single inheritance in certain cases). Since there is no member data in CObject, virtual inheritance is not needed to prevent multiple copies of a base class's member data.

The real answer is no, virtual inheritance will not solve the ambiguity problems illustrated above. For example, the Dump virtual member function is still ambiguous (since CFrameWnd and CObList implement it differently).

Therefore we recommend following the steps above to provide disambiguation:

The run-time typing mechanism supported by MFC in CObject uses the macros DECLARE_DYNAMIC, IMPLEMENT_DYNAMIC, DECLARE_DYNCREATE, IMPLEMENT_DYNCREATE, DECLARE_SERIAL and IMPLEMENT_SERIAL. These give the ability to do a run-time type check to allow for safe cast-downs.

These macros only support a single base class and will work in a limited way for multiply inherited classes. The base class you specify in IMPLEMENT_DYNAMIC or IMPLEMENT_SERIAL should be the first (or left-most) base class. For example,

class CListWnd : public CFrameWnd, public CObList
{
    DECLARE_DYNAMIC(CListWnd)
    ...
};
IMPLEMENT_DYNAMIC(CListWnd, CFrameWnd)

This will allow you to do type checking for the left-most base class only. The run-time type system will know nothing about additional bases (CObList in this case).

For the MFC message map system to work correctly, there are two additional requirements:

• There must be only one CWnd-derived base class.

• The CWnd-derived base class must be the first (or left-most) base class.

In the example above, CFrameWnd is the first base class.

Some examples that will not work:

class CTwoWindows : public CFrameWnd, public CEdit
    { ... };
        // error : two copies of CWnd

class CListEdit : public CObList, public CEdit
    { ... };
        // error : CEdit (derived from CWnd) must be first

The following sample is a stand-alone application that consists of one class derived from CFrameWnd and CWinApp. This way of structuring an application is not a recommended, but this is an example of the smallest MFC application with one class.

#include <afxwin.h>

class CHelloAppAndFrame : public CFrameWnd, public CWinApp
{ 
public:
    CHelloAppAndFrame()
        { }

    // Necessary evil for MI disambiguity
    void* operator new(size_t nSize)
        { return CFrameWnd::operator new(nSize); }
    void operator delete(void* p)
        { CFrameWnd::operator delete(p); }

// Implementation
    // CWinApp overrides
    virtual BOOL InitInstance();
    // CFrameWnd overrides
    virtual void PostNcDestroy();
    afx_msg void OnPaint();

    DECLARE_MESSAGE_MAP()

};

BEGIN_MESSAGE_MAP(CHelloAppAndFrame, CFrameWnd)
    ON_WM_PAINT()
END_MESSAGE_MAP()

// since the frame window is not allocated on the heap, we must
// override PostNCDestroy not to delete the frame object
void CHelloAppAndFrame::PostNcDestroy()
{
    // do nothing (do not call base class)
}

void CHelloAppAndFrame::OnPaint()
{
    CPaintDC dc(this);
    CRect rect;
    GetClientRect(rect);

    CString s = "Hello, Windows!";
    dc.SetTextAlign(TA_BASELINE | TA_CENTER);
    dc.SetTextColor(::GetSysColor(COLOR_WINDOWTEXT));
    dc.SetBkMode(TRANSPARENT);
    dc.TextOut(rect.right / 2, rect.bottom / 2, s);
}

// Application initialization
BOOL CHelloAppAndFrame::InitInstance()
{
    // first create the main frame
    if (!CFrameWnd::Create(NULL, "Multiple Inheritance Sample",
        WS_OVERLAPPEDWINDOW, rectDefault))
        return FALSE;

    // the application object is also a frame window
    m_pMainWnd = this;          
    ShowWindow(m_nCmdShow);
    return TRUE;
}

CHelloAppAndFrame theHelloAppAndFrame;

Other Resources