I have the following code:
In DLL1:
in .h file:
class MyClass
{
public:
MyClass();
private:
std::string m_name;
};
class __declspec(dlle
Without further code available for analysis, an important bug I see in your posted code is that your Foo
class is a resource manager violating the so called Rule of Three.
Basically, you dynamically allocate an Impl
instance in the Foo
constructor using new
, you have a virtual destructor for Foo
releasing the managed resource (pimpl
) with delete
, but your Foo
class is vulnerable to copies.
In fact, the compiler generated copy constructor and copy assignment operators perform member-wise copies, which are basically shallow-copies of the pimpl
pointer data member: this is a source of "leaktrocities".
You may want to declare private copy constructor and copy assignment for Foo
, to disable compiler-generated member-wise copy operations:
// Inside your Foo class definition (in the .h file):
...
// Ban copy
private:
Foo(const Foo&); // = delete
Foo& operator=(const Foo&); // = delete
Note: The C++11's =delete
syntax to disable copies is not available in MSVC 2010, so I embedded it in comments.
Not directly related to your problem, but maybe worth noting:
In your Foo::Impl
structure, since the m_vec
data member is already public
, I see no immediate reason to provide an accessor member function like GetVector()
.
Starting with C++11, consider using nullptr
instead of NULL
in your code.