Backward Compatibility with DLLs

This and the following articles, I personally feel very interesting.

It’s related to the “backward compatibility” of the DLLs.

If you are distributing your DLLs to people or 3rd party, whom you expect to use them, you should be very careful about the interface you expose out of the DLLs.

Consider you are distributing a DLL, which has an exported class of some size and few public functions. If you update the same DLL in future and redistribute it, you cannot always expect the users to re-link their application with your new DLL. In such cases, users of the DLL expect the same interface what you had provided in the earlier release. If by any way there is a change in the interface, it results in failure of backward compatibility.

Let’s take an example to explain this situation. The following is a class which you are exporting as part of your DLL,

#define DLL_EXPORT __declspec(dllexport)

class DLL_EXPORT ExampleExport
{
    public:
        ExampleExport();
        ~ExampleExport();

        void function1();
        int function2();

    private:

        int m_member1;
        int m_member2;
};

In a future release you updated this class to have an additional member variable,

class DLL_EXPORT ExampleExport
{
    public:
        ExampleExport();
        ~ExampleExport();

        void function1();
        int function2();

    private:

        int m_member1;
        int m_member2;
        int m_member3; // <<---- a new member variable added
};

You can observer that the class size has been changed. Earlier it was 8 bytes (assuming int as 4 bytes) and it’s changed to 12 by adding an additional integer member variable.

Consequence: For an end user application, which is not re-linked with the updated DLL, the size of the class is still 8 bytes. Since the application was compiled and linked with the first version of DLL, the size is still the same even after they started using the new DLL. The application may have unpredicted behavior.

Resolution: This problem needs to be addressed before we release the first version of the DLL. Of course we cannot restrict the size of the class to not to change in future. We may need to update it by adding or removing new member variables. One solution is to force the end user application to not to construct the object by itself.

• Make constructor private.
• Export a new static member function which creates an object by calling private constructor

class DLL_EXPORT ExampleExport
{
public:
    ~ExampleExport();

public:
    static ExampleExport* Instance();

public:
    void function1();
    int function2();

private:
    ExampleExport(); // <<---- private constructor

private:
    int m_member1;
    int m_member2;
    int m_member3; // <<---- a new member variable added
};

This forces the client application to use ExampleExport::Instance() function always to construct an object and since the definition of Instance() is part of the DLL, 12 bytes will be allocated with the new DLL.

Let’s have a look at another solution for the same problem, in the next article.

Forward Declarations

We can use forward declaration to speedup the compilation and to reduce the interdependencies between different modules.

Consider following CServer and CClient classes, declared in Server.h and Client.h header files respectively.

Server.h

#include "Client.h"

class CServer
{
public:
CServer();
virtual ~CServer();

void SendMsg(CClient &clnt);

private:
CClient *m_ptrClient;
};

In this case it will always be more efficient to omit the inclusion of the header file Client.h, instead we can use forward declaration as shown below,

class CClient;

class CServer
{
public:
CServer();
virtual ~CServer();

void SendMsg(CClient &clnt);

private:
CClient *m_ptrClient;
};

This is sufficient in this case because of the reason that C++ compiler is optimized enough and it doesn't need to know about the size and interfaces of the class CClient within the declaration of the CServer class.

However we have to include the Client.h header in Server.cpp where the actual definition of the member functions exist.

Below are some use cases which indicates the usage of forward declarations,

class CClient;

class CServer
{
public:
CServer();
virtual ~CServer();

void SendMsg(CClient clnt); // non-ref/pointer parameter

private:
CClient *m_ptrClient;
};

Usage of forward declaration is valid even though we have non-reference or non-pointer parameter in the member function.

Below is a case where we cannot use forward declaration,

class CClient;

class CServer
{
public:
CServer();
virtual ~CServer();

void SendMsg(CClient clnt) { clnt.updateMsg(); } // inline definition

private:
CClient *m_ptrClient;
};

Cannot use forward declaration here because SendMsg has it's inline definition which is actually using CClient::updateMsg(). In this case we need to include the header Client.h within Server.h

One more case where we can not use forward declaration,

class CClient;

class CServer
{
public:
CServer();
virtual ~CServer();

void SendMsg(CClient clnt);

private:
CClient m_client;
};

Since the member variable m_client within CServer is of type CClient, compiler need to know about the CClient. We cannot use the forward declaration here.

The cause of compilation speed increase

The increase in speed by forward declaration is due to the fact that header files can be included multiple times, whereas implementation files (CPP) are not. Therefore, keep the heaer files as simple as possible.

Rule of Thumb : "If the compiler doesn't need it, you won't have to do it." C++ is well optimized.

dynamic_casting with pointers and references

First of all a very warm happy new year to all the readers. Its been a while since the last post.

Today I intend to write about dynamic_cast again. There's already an article about dynamic_cast. The reason why I'm writing about this is to show with some samples how we can use dynamic cast with pointers and also with references.

Yes, RTTI can be implemented both with pointers and references.

Below sample shows how to use dynamic_cast with pointers. I have considered the same example classes which were there in the dynamic_cast article .

void ProcessButtonEvent(CControlIface *pControl)
{
    // Here we need make sure safe down-cast happens
    CButtonControl *pButton = dynamic_cast <CButtonControl *> (pControl);

    // casting works fine here since we had passed pControl1

    if(pButton != NULL)
    {
        pButton->OnClick();
        // We can now safely call OnClick() of CButtonControl
    }
    else
    {
        cout << "dynamic_cast failed. pControl is not pointing to instance of CButtonControl"<<endl;
    }
}

We need to note here that whenever dynamic cast fails with pointers it returns NULL. This is the reason why we are checking for

pButton!=NULL

Lets try dynamic casting with references,

void ProcessButtonEvent(CControlIface &Control)
{
    // Here we need make sure safe down-cast happens
    try{
    CButtonControl &Button = dynamic_cast <CButtonControl &> (Control);
    Button.OnClick();
    }
    catch(bad_cast)
    {
        cout << "Caught: bad_cast exception. This control is not a button"<<endl;
        return;
    }
}

In case of references if dynamic_cast fails, it throws bad_cast exception. This is the reason why we are catching the exception in the above code sample.

Please note that some old compilers may not support dynamic_cast. In that case its high time for you to upgrade your C++ compiler!