Unmanaged DLLs in C++

Question

I've been reading many a tutorial/article on unmanaged DLLs in C++. For the life of me, however, I cannot seem to grasp the concept. I'm easily confused by the seeming disagreement about whether it needs a header file, how to export it, whether I need a .lib file and what have you.

So, let's assume I have just a function like so:

public int calculateSquare(int num)
{
    return num*num;
}

Ignoring the actual code, what do I require to make this simple function, by itself, into a DLL which I can then call? Do I just add __dllexport or whatever it is to the first line or do I require a header? I am perplexed by all of this.

Answer 1

I cannot stress this enough, the C++ compiler does not see header files, after the preprocessor is done, there's just one big source file ( also called the compilation unit ). So strictly you don't need a header to export this function from a dll. What you do need is some form of conditional compilation to export the function in the dll that you are compiling and to import it in the client code.

Typically this is done with a combination of macros and header files. You create a macro called MYIMPORTEXPORT and through the use of macro conditional statements you make it work like __declspec ( dllexport ) in the dll, and __declspec( dllimport ) in the client code.

in file MYIMPORTEXPORT.h

#ifdef SOME_CONDITION
#define MYIMPORTEXPORT __declspec( dllexport )
#else
#define MYIMPORTEXPORT __declspec( dllimport )
#endif

in file MyHeader.h

#include <MyImportExport.h>

MYIMPORTEXPORT public int calculateSquare(int num)
{
    return num*num;
}

in dll .cpp file

#define SOME_CONDITION

#include <MyHeader.h>

in client code .cpp file

#include <MyHeader.h>

Of course you also need to signal to the linker that you are building a dll with the /DLL option.

The build process will also make a .lib file, this is a static lib - called the stub in this case - which the client code needs to link to as if it were linking to a real static lib. Automagically, the dll will be loaded when the client code is run. Of course the dll needs to be found by the OS through its lookup mechanism, which means you cannot put the dll just anywhere, but in a specific location. Here is more on that.

A very handy tool to see whether you exported the correct function from the dll, and whether the client code is correctly importing is dumpbin. Run it with /EXPORTS and /IMPORTS respectively.

Answer 2

QBziZ' answer is right enough. See Unmanaged DLLs in C++

To complete it: In C++, if you need to use a symbol, you must tell the compiler it exists, and often, its prototype.

In other languages, the compiler will just explore the library on its own, and find the symbol, et voilà.

In C++, you must tell the compiler.

See a C/C++ header as a book table of contents

The best way is to put in some common place the needed code. The "interface", if you want. This is usually done in an header file, called header because this is usually not an independent source file. The header is only a file whose aim is to be included (i.e. copy/pasted by the preprocessor) into true source files.

In substance, it seems you have to declare twice a symbol (function, class, whatever). Which is almost an heresy when compared to other languages.

You should see it as a book, with a summary table, or an index. In the table, you have all the chapters. In the text, you have the chapters and their content.

And sometimes, you're just happy you have the chapter list.

In C++, this is the header.

What about the DLL?

So, back to the DLL problem: The aim of a DLL is to export symbols that your code will use.

So, in a C++ way, you must both export the code at compilation (i.e., in Windows, use the __declspec, for example) and "publish" a table of what is exported (i.e. have "public" headers containing the exported declarations).