How to split a C++Builder app into DLLs

Question

I've been told several times that I should consider splitting parts of my app into separate DLLs (to speed up linking, etc.) and am trying to figure out how that works.

I understand that I need to add __declspec(dllexport) to every header file declaration that I plan on using. That seems tedious, but it's doable.

How do I get the app + DLLs to run? In a simple test project, the only way I found that works is to manually copy the DLL from the DLL project's build output directory to the exe project's build output directory. I know I can set up a post-build step to do this, but I'd expect the IDE to have some way to automate having an app project use a DLL project when they're part of the same project group.

How do I debug the app + DLLs? I see where I can specify a host application for a DLL under Project -> Options -> Debugger, but so far, I've only been able to figure out how to debug one project at a time. I'd really like to be able to set breakpoints anywhere in the codebase and single-step through anywhere in the codebase (instead of being stopped at project boundaries), and I can't figure out how to do that.

Answer 1

I understand that I need to add __declspec(dllexport) to every header file declaration that I plan on using. That seems tedious, but it's doable.

What you should do is create a #define in your DLL's header file that maps to dllexport when the header is compiled by the DLL project, and maps to dllimport when compiling in other projects. For example:

#ifndef MyDLLH
#define MyDLLH

#ifdef _BUILDING_DLL_
#define MY_EXPORT __declspec(dllexport)
#else
#define MY_EXPORT __declspec(dllimport)
#endif

#ifdef __cplusplus
extern "C" {
#endif

MY_EXPORT type callingconvention SomeFunc(parameters);
#ifdef __cplusplus
}
#endif

#endif

Then you can define _BUILDING_DLL_ in your DLL project only, either in the Conditionals list of the Project Options, or in your code above any #include statements for the header file, eg:

#define _BUILDING_DLL_
#include "MyDll.h"

How do I get the app + DLLs to run?

The DLL project generates a .lib file that is used for static linking to the DLL's exported functions. You can add that .lib file to your EXE project and then call the DLL functions like any other function call. Or you can dynamically load the DLL functions at runtime using the Win32 API LoadLibrary() and GetProcAddress() functions, in which case you do not use the .lib file at all.

In a simple test project, the only way I found that works is to manually copy the DLL from the DLL project's build output directory to the exe project's build output directory.

The EXE's folder is the first place the OS looks for the DLL, but it is not the only place the OS can look. MSDN documents how DLL's are located at runtime:

Dynamic-Link Library Search Order

I know I can set up a post-build step to do this, but I'd expect the IDE to have some way to automate having an app project use a DLL project when they're part of the same project group.

Just being part of the same project group is not enough. The projects are compiled independantly of each other. However, you can set the DLL project as a dependancy of the EXE project (or just make sure the DLL projct is higher up on the build order then the EXE project) so the DLL is compiled first, then use the DLL's PostBuild events to move the compiled .lib and .dll binaries where needed, and lastly add the DLL's compiled .lib file to the EXE project so the DLL is used at runtime.

How do I debug the app + DLLs?

You have a couple of choices:

To debug just the DLL by itself, load the DLL project into the IDE, go into the Run parameters, and set the compiled EXE at the Host application. You can then Run the DLL project as if it were an EXE project. The EXE will be executed and the debugger will attach to the DLL once it is loaded into memory.

To debug both projects at the same time, load the EXE project into the IDE instead, and make sure the DLL's source folder is specified in the Debug Souce path of the Project Options. You can then run the EXE project normally, step into the DLL functions when they are called, set breakpoints in the DLL's source, etc.