Converting a C++ project so far developed as standalone executable into a DLL

(I'm using Microsoft Visual Studio 2010 on a Windows 7 64 bit machine)

I have developed a C++ program that is more of a library which became quite complex over time. It does right now work as a simple executeable, but I'd like to convert it into a DLL so the functionality can be accessed by other programs easily.

I'm not at all experienced in working with DLLs, but I want to avoid much additional work and code changes in the process.

I know that I can select the compile target to "DLL", but I have the feeling that alone won't d开发者_如何学Goo the job.

• If I successfully compiled my project into a DLL file, how do I use the functions in it from an executable project?

• Can I avoid using _dllexport and importing every function per-name?

• How does one statically link a DLL, and what are the (dis)advantages of this?

Honestly, I would take a look at the DLL export docs and pick whatever export method works best for you. In any case, you can simply reference exported functions by name from your client apps, as you would with a static library.

When you build the project as a DLL, the IDE will generate

1. The DLL file for runtime and
2. a LIB file containing exported function resolution information - that's the one you link against.

By definition, you cannot statically link a DLL (that's DYNAMIC link library) - instead, you link to a library that exports the functions from the DLL, and then the DLL loads at runtime, either automatically on process start or on demand. It's also possible to load the DLL completely on demand without any static linkage (see LoadLibraryEx etc).

Since you're using C++ I'm assuming you're exporting classes(?). There's a really good example over on CodeProject which walks you through a few options. The cleanest of which is to use an abstract interface:

A C++ abstract interface (i.e., a C++ class that contains only pure virtual methods and no data members) tries to get the best of both worlds: a compiler independent clean interface to an object, and a convenient object oriented way of method calls. All that is required to do is to provide a header file with an interface declaration and implement a factory function that will return the newly created object instances. Only the factory function has to be declared with the __declspec(dllexport/dllimport) specifier. The interface does not require any additional specifiers.

You can't statically link to a Dynamic Link Library. If you want to link statically, create a .lib instead.

• To use your DLL you have to #include the header file(s) associated with your dll/lib and link with the .lib file that is associated with your .dll

• You need the _declspec(dllexport)/_declspec(dllimport) to indicate you want to export/import the contents of the dll. This can be easily accomplished as follows

 #ifdef FOO_EXPORTS
      #define EXPORT_ME __declspec(dllexport)
 #else
      #define IMPORT_ME __declspec(dllimport)
 #endif

in the headers for your dll you simply need to #define FOO_EXPORTS and place the EXPORT

foo.hpp

class EXPORT_ME foo2();

void EXPORT_ME foo_funct(foo2 *foo_ptr);

and any file that needs to use the exported items simply needs to call the the methods defined in the foo.hpp header (the default behavior is to import)

use_foo.cpp

main()
{
      #include "foo.cpp";
foo2 myfoo;
foo_funct(&my_foo);
}

• As others have said, a lib is statically linked and a dll is dynamically linked. Any referenced elements when linked statically are placed in-line at compile time into your source and generally produce a larger program (as far as file size), while dynamically linked elements are linked in at run-time so the file size is usually smaller. There are many other pros/cons to static vs dynamic - I recommend you follow Doc Browns link for more info

Switch to gcc under MinGW. Building and linking to a DLL is just as easy as building and linking to a static library. It even handles C++ name mangling transparently (but then the calling program also needs to be compiled with gcc).