• entries
  • comments
  • views

Dynamic Link Libraries

Sign in to follow this  


Handling Resources
DLLs have their strong points, but one of their weak points deals with memory. In general: If you link to a DLL statically, it will be placed in your process space, and thus share your heap. When you allocate memory, you can free it from the application or the DLL, since both are using the same heap. However, if you are using dynamic linkage, then you aren't so lucky. The DLL will have it's own heap, and hence memory allocated by the DLL must be released by the DLL, not by the application. Trying to release the memory that the DLL allocated in the application can result in a variety of different bugs, most of the time, however, it will just crash with an access violation.

In general, you should stick to the following simple rule: 'He who allocates it, deallocates it.' Basically, if the DLL allocates a chunk of memory, then it should be the one to deallocate it. Of course, the case here is not so clear cut as one would hope. Passing strings, for instance, can result in under the cover allocations and copy operations, along with their associated deallocations. The easiest way to avoid problems is to either pass raw data, such as character pointer, or to pass constant references. This will force the user to make a copy to make changes, thus preventing allocation errors.

Other tricks involve providing custom allocators to your standard library which all allocate from the same heap. This solution, however, is more complex in general than just obeying the simple rule I stated above, but can have certain advantages.

Our first DLL
First of all, this assumes Visual Studio, and that you've created an empty DLL project and added a source file and a header.

#ifndef SIMPLE_AA9B8090_F6C7_4a9c_8858_22D4C92B1EC7
#define SIMPLE_AA9B8090_F6C7_4a9c_8858_22D4C92B1EC7

#ifdef _MSC_VER
#define DLLIMP __declspec(dllexport)
#define DLLIMP __declspec(dllimport)
#else //_MSC_VER
#define DLLIMP
#endif //_MSC_VER


struct IStrange {
virtual std::string const& GetName() const = 0;
virtual void PrintString(std::string const& str) = 0;
virtual void Release() = 0;
virtual ~IStrange() = 0 {};

extern "C" DLLIMP IStrange* GetStrange();
typedef IStrange* (*GetStrangeSignature)();

#endif //SIMPLE_AA9B8090_F6C7_4a9c_8858_22D4C92B1EC7

First off, the macros should be pretty self explanatory, SIMPLEDLL_EXPORTS is defined for me by Visual Studio (it's in the build options under C++) and is the name of the project with EXPORTS appended to it. If that is defined, then DLLIMP will be replaced with __declspec(dllexport), which marks a function as being exported. Otherwise it is replaced by __declspec(dllimport), which marks a function as being imported.

The structure is used to define an interface with three pure virtual functions, note the constant referenced strings. You should also note that the destructor is protected. This prevents the user from calling delete on an IStrange pointer. We also export a single function, GetStrange, which returns a pointer to an IStrange interface. We also provide a typedef of the function signature of the GetStrange function, which I'll demonstrate the usage of later.

Next we wish to create a class that implements the IStrange interface.

#ifndef STRANGEIMPL_F86F9C31_5E3B_4f88_82E4_B8EA1F1BAB26
#define STRANGEIMPL_F86F9C31_5E3B_4f88_82E4_B8EA1F1BAB26

#include "Simple.h"

class StrangeImpl : public IStrange {
std::string const& GetName() const;
void PrintString(std::string const& str);
void Release();
std::string name;

#endif //STRANGEIMPL_F86F9C31_5E3B_4f88_82E4_B8EA1F1BAB26

As we can see above, the class is just a simple implementation of the base class, with the addition of a constructor and a single private variable. The definition of the methods:

#include "StrangeImpl.h"

StrangeImpl::StrangeImpl() : name("StrangeImpl") {

StrangeImpl::~StrangeImpl() {

std::string const& StrangeImpl::GetName() const {
return name;

void StrangeImpl::PrintString(std::string const& str) {

void StrangeImpl::Release() {
delete this;

IStrange* GetStrange() {
return new StrangeImpl();

Note the GetStrange method is found here, and that it returns an instance of our derived class. Another thing that you should note is that the GetName method returns a constant reference to the name string, which is initialized in the constructor to the name of our class...for no particular reason.

If you compile and link this, you will end up with two output files, a dll file, and a lib file. The lib is used when you wish to statically link to a DLL. For both dynamic and static linking, you are required to have the DLL file available.
Sign in to follow this  


Recommended Comments

I am much pleased! [grin]

After reading the notes on unshared resources, however, I see there isn't much I should be using them for at this point. Which is probably a good thing - I'd probably end up hurting myself somehow anyway.

EDIT: was browsing my FTP and found that ^. Swapped with previous image.

Share this comment

Link to comment
What is the performance difference of using the library dynamically compared to linking statically if any?

Right now I have both renderers just as projects in the solution and I say which I would like to compile against. It is not an optimal solution but works for the time being while building it up. Although if there is only a negligable performance hit I think I am going to switch my renderers to .DLLs which would be much better.

Instead of statically linking my engine to the application would it be fine to have the engine as a DLL, renderers as DLLs, etc? Or will I start incurring performance loss at some point?

Share this comment

Link to comment
Well, there's pretty much just an extra pointer dereference, if that.

Share this comment

Link to comment
Another idea I've seen mentioned in regards to sharing memory across a process and a dll is to make the objects "com-like". Basically, something like this:

class Object
Object () {}
~Object () {}

Object *create ();
void release ();

//cpp file
Object *Object::create () { return new Object; }
void Object::release () { delete this; }

Do you think this is a viable solution to the memory between a process and its libraries? Instead of delete/free-ing them, you would just call the release function and it will release the object from the heap it was allocated on. I've been looking for some options other than having static linkage.


Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now