views:

605

answers:

5

Hi,

I am developing a C++ library that I want to pass on to my team. The library has just one class with a bunch of methods.

So, I have developed the class definition file (X.cpp) and a corresponding class declaration file (X.h).

Here are my questions --

  1. In Visual Studio 2005, whats is the most straight forward way to build this library as a DLL, such that I get the following files: X.lib : which I can pass to my team so they can link against my library X.dll : which I can pass to my team for run-time

  2. Instead of a DLL, should I rather be going the static library way ?? If so, how do I go about doing this in Visual Studio 2005 & will this give me a X.lib file that I can pass on to my team ?

Any explanations or references are very welcome.

Thank you very much.

+1  A: 

From your description, it looks like you already have a Visual C++ project (correct me if I'm wrong). If so, when you go into project properties, under "General" you can find "Configuration Type" - switch it to "Static library" or "Dynamic library" as needed.

If you choose "Static library", then you will just get a .lib file that can be immediately used.

If you choose "Dynamic library", and you export any functions from your DLL (e.g. by marking them with __declspec(dllexport)), an export .lib will be generated automatically.

It's hard to tell which option is preferable without knowing the specifics of what you're doing. In general, I'd recommend defaulting to static libraries, because it's usually good enough, and there are more traps when dealing with DLLs (especially ones that export C++ symbols).

Pavel Minaev
And using dynamic library one should remember about possible runtime library conflicts.
Kirill V. Lyadvinsky
+2  A: 

The easiest way to build a DLL, is New->Project->Win32 Console Application. Then on the dialog select DLL and select "Exports Symbols". This will synthesize a dll with a .h, and .cpp file which demonstrate how to export your classes. You can get rid of this .h/.cpp but first import your class add the appropriate #ifndef statements. Now as far as DLL versus Static library if its a single small class, that doesn't change particularly often you might be better off with a static library, its simple, its concise, it doesn't add another dependency which needs to be shipped with your product. A DLL is nice if the code in the .cpp file changes often (ie. the function implementations) because you can just swap in the new DLL.

DeusAduro
A: 

I struggle with this too sometimes.. because I can't find where the elusive setting is within C++ Project Properties.. So I decided to jot it down for my own sanity as a blog post.

HTH

Gishu
A: 

I think that, in most cases, a dll is a better choice than a static lib because your team will not have to recompile their code when you distribute a new version of your library.

luc
A: 

Thanks for all the answers - very helpful !

Another flavor to the question follows:

The library I've developed (i.e, X.cpp / X.h) uses a third-party dll library (ie, Y.lib / Y.dll). Say I build my library as a DLL and pass on the X.lib/X.dll files to my team. Then --

  1. For Linking: Does X.lib contain Y.lib OR do I need to also give my team the Y.lib ?

  2. For runtime: Does X.dll contain Y.dll OR do I need to also give my team the Y.dll ?

  3. Does the scenario change If I build my library as a static one ? I.e, will the X.lib I get also have Y.lib ?

Thank you very much.