DLLs vs Static Libraries and Interfaces

[DeXecipher]

Which do you prefer to make/use? I'm debating whether to go with static libraries so that I don't have to manually load objects for most of my software project. Which is better? Is it ok for a project to use a mix, or is it generally a good idea to stick with using one alone.

One more question, lets say I have a separate interface library, (abstract classes), If I have my Interfaces hint at being dynamically linked ie. __declspec(dllexport) or __declspec(dllimport) will I need to load the dll that the Compiler/IDE makes for each project that uses such headers. Do the header files, get encoded into independant objects files first or is it on as a needed basic, (into the object file specification of the Classes/Functions that uses them?

Thanks.

[Disch]

Which do you prefer to make/use?

When creating a lib, it should be able to do both, as the decision of how to link should be up to the user.

When using a lib (on Windows), I prefer static linking for small-medium sized projects. But it depends on the lib also.

Which is better?

Both have tradeoffs.

Advantages to static linking
1) No need to worry about the user having the right version of the right lib installed on their machine -- or having to distribute it with your program. It's built right into the program.

2) No need to worry about having to distribute extra dlls with your program.

3) Static linking links the lib as part of the build process, which gives the toolchain more opportunities for optimizations. Compare the file size of a dynamic linked exe+dll to the size of a statically linked exe. The static linked one will virtually always be smaller (however this assumes the dll will be distributed with your program). There are also performance gains.

Advantages to dynamic linking
1) Multiple programs can share the same dll. So if you have a lot of small programs using a library, it is likely more size-efficient to store the library as a separate dll so it does not have to be built into each program. (Note that this becomes problematic with C++ as C++ built DLLs tend to not work unless they were built with the same version of the same compiler as the exe using them.)

2) Having lots of DLLs instead of a single large EXE makes it easier to do "patch style" program updates after a release. If you want to do a bugfix to a program that has been out for a while... you can replace just one or two smaller dlls rather than having to replace the entire suite.



For more or less "standard" lib that everyone is going to have installed on their machine (things like DirectX, OpenGL, etc), then I typically go with dynamic linking. But for things like SFML, which very few people are going to have (and even if they do have it, it might be the wrong version), then I go with static.

If I have my Interfaces hint at being dynamically linked ie. __declspec(dllexport) or __declspec(dllimport) will I need to load the dll that the Compiler/IDE makes for each project that uses such headers

Regardless of static/dynamic linking... projects that use the headers will have to link to a library file (*.lib for msvs, *.so and *.a for gcc). Linking to that lib will cause your program to automatically load the appropriate dll (assuming dynamic linking) on startup.

Failure to link to the lib will cause linker errors (typically in the form of "unresolved external symbol") when you try to build the program.

Do the header files, get encoded into independant objects files first or is it on as a needed basic, (into the object file specification of the Classes/Functions that uses them?

Not sure I understand this question. Header files don't get encoded into anything.

In a typical executable, source files (ie: the .cpp files) get built into an *.exe.

In a static lib, source files get built into a *.lib or a *.a.

In a dynamic lib, source files get built into a *.dll -- and a separate *.lib or *.so is also created to make it easier to link to.

[DeXecipher]

Header files don't get encoded into anything.

I read on wikipedia, sigh*, that header specifications (methods,classes, and so on) get built into the .cpp (source/imp) which then gets turned into object code when the compiler compiles. Thanks.

[Disch]

Well... there's some truth to that. I might have just been being hypertechnical.

The functions and stuff you declare in the header will obviously have an impact on how the library is built. So things like the __declspec decorators are still significant.

[kbw]

http://software.intel.com/en-us/articles/keeping-memory-in-mind/

[DeXecipher]

this was a great read.