When to put a whole C++ class framework into a DLL?

Question

I am about to write a C++ framework that will later be used by different C++ applications. The framework will provide one main class, which will be instantiated by the application. That main class will make use of some other classes within the framework. And there will be some helper classes, to be used directly by the application.

Now I am thinking of how I should encapsulate that class framework. I could write the header and source files as usual, and then include those in the applications that will make use of the framework, so that all will be compiled in one go together with the application.

But I am not sure whether this is "the best" approach in my case. Wouldn't it be an option to put the whole framework into a DLL and then link that DLL to the applications? However, I also read that it is often not the best idea to let a DLL export whole classes, and that this approach might lead to difficulties when using STL templates as data members.

Can you recommend an approach to me, maybe something else I have not mentiond above, incl. the pros and cons of all these options?

Answer 1

You can create a C interface using opaque pointers, which is needed in your case because of the varying types and versions of compilers involved. Note that you may not accept or return non-C types, unless you also wrap them in opaque pointers. It's not hard, but there's a bit of work needed on your behalf.

Assuming a class 'YourClass', you would create a YourClassImpl.h and YourClassImpl.cpp (if needed) containing your C++ class code.

YourClassImpl.h

class YourClass
{
    private:
        int value = 12345;

    public:
        YourClass() {}
        ~YourClass() {}

        int getThing() { return value; }
        void setThing(int newValue) { v = newValue}
};

You would then create a YourClass.h which would be your C header file (to be included by the users of your DLL), containing an opaque pointer typedef and the declarations of your C-style interface.

YourClass.h

#ifdef MAKEDLL
#  define EXPORT __declspec(dllexport) __cdecl
#else
#  define EXPORT __declspec(dllimport) __cdecl
#endif

extern "C"
{
    typedef struct YourClass *YC_HANDLE;
    EXPORT YC_HANDLE CreateYourClass();
    EXPORT void DestroyYourClass(YC_HANDLE h);
    EXPORT int YourClassGetThing(YC_HANDLE h);
    EXPORT void YourClassSetThing(YC_HANDLE h, int v);
}

In YourClass.cpp you would define those functions.

YourClass.cpp

#include "YourClass.h"
#include "YourClassImpl.h"
extern "C"
{
    EXPORT YC_HANDLE CreateYourClass()
    {
        return new YourClass{};
    }

    EXPORT void DestroyYourClass(YC_HANDLE h)
    {
        delete h;
    }

    EXPORT int YourClassGetThing(YC_HANDLE h)
    {
        return h->getThing();
    }

    EXPORT void YourClassSetThing(YC_HANDLE h, int v)
    {
        h->setThing(v);
    }
}

In your users code they would include YourClass.h.

TheirCode.cpp

#include "YourClass.h"

int ResetValue(int newValue)
{
    YC_HANDLE h = CreateYourClass();
    auto v = YourClassGetThing(h);
    YourClassSetThing(h, newValue);
    DestroyYourClass(h);

    return v;
}

The most usual way of linking to your DLL would be with LoadLibrary/GetProcAddress - I'd also advise adding a .def file to your project to ensure that the functions are named 'nicely' and are not difficult to access because of any name decoration.

Some issues to keep an eye out for:

1. Only the standard C fundamental types can be passed back and forth across the interface. Don't use any C++ specific types or classes.
2. PODs and arrays of PODs may be safe for you to use, but watch out for any packing or alignment issues.
3. Exceptions must not cross the interface boundaries - catch anything that gets thrown and convert it to a return code or equivalent.
4. Ensure that memory allocated on either side of the boundary is deallocated on the same side.