Re: exporting classes in a DLL using the PIMPL idiom
On Sun, 20 Jan 2008 16:45:09 +0000, "2b|!2b==?" <user@domain.invalid>
wrote:
I have asked how to do this several times in this ng, however, the
responses I have received so far, though useful, have not really
explained (i.e. provided a simple example) of how I may do this.
I have a project that consists of several modules that build into DLLs.
Mnay of these DLLs use classes defined in other DLLs. The important
thing to note is that I am in control of all of the sources for all of
the projects, and I am using the same compiler to build all of the
modules. I have a workflow that builds all of the modules as part of my
build process, so there is no chance of different modules being built by
different compilers etc.
Ok. having got that out of the way - my main question is this - how may
I use classes defined in one DLL, in another module - without using
__declspec macros and/or def files?.
I presume you have your reasons for wanting to go to the trouble of using
the pimpl idiom, but the scenario you've described is the one for which
using __declspec(dllexport|dllimport) on whole classes works fine.
Someone (I can't rember who),
suggested that I could 'export' the class using the PimPL idiom, and
then simply include the header file and .lib file in the referencing
project - unfortunately, they did not provide an example, and after
several days of googling, I am none the wiser.
Perhaps that's for the best. It's a lot more work than using __declspec.
Indeed, using the pimpl idiom amounts to work above and beyond using
__declspec or a .def file, one of which you cannot escape using, because
you have to be able to create instances of these classes.
If I have a module (builds into a DLL - moduleA.dll), that has the
following classes,
Fred, Barney, Alice
how may I use the PiMPL idiom to 'export' these classes so that they may
be used in another module (moduleB) by simply including the header files
Fred.h, Barney.h and Alice.h and linking to moduleA.lib ?
In your situation, the easiest approach is to dllexport whole classes. It
will allow you to "simply include the header files Fred.h, Barney.h and
Alice.h and link to moduleA.lib". Moreover, you will be able to "use" the
classes as real C++ classes, instead of the COM-like interfaces Alex
described in his reply to you. Indeed, I think you may be confusing the
pimpl idiom with COM simulation, because pimpl and dllexporting whole
classes aren't mutually exclusive, whereas simulating COM and dllexporting
the simulated interface classes are mutually exclusive. For an example of
simulating COM, see Alex's message. Here's an example of the pimpl idiom
where the wrapper class is dllexported:
x.h:
class X_EXPORT X
{
private:
class X_impl; // NB: Not dllexported
public:
X();
~X();
void f();
virtual void g();
private:
// Copyguard
X(const X&);
void operator=(const X&);
private: // Data section
X_impl* pimpl;
};
x.cpp:
#include <bunch of headers>
class X::X_impl
{
... implement X
};
X::X()
: pimpl(new X_impl)
{
}
X::~X()
{
delete pimpl;
}
void X::f()
{
pimpl->f();
}
void X::g()
{
pimpl->g();
}
The important thing for pimpl is to ensure that all of X's member functions
are defined in the DLL instead of being inline. This moves the compilation
dependencies into the file that defines X_impl, which helps compilation
speed for files that #include x.h, and it also ensures that no one outside
the DLL tries to use X_impl, which would cause linker errors.
So what's the difference between this and COM simulation? I suppose the
latter might be useful if you wanted to use different compilers that mangle
names differently, but you've said you're using the same compiler. The COM
simulation also requires all public functions DLL clients can use to be
virtual, because they aren't exported and thus cannot be linked to by name.
--
Doug Harrison
Visual C++ MVP