Linking Libraries - VC++ 2010 - General

[Nuclaer]

I am having some confusion about how the linking of separate or 'third party' libraries works. First off, what is the difference between static linking (.lib file) and a dynamic link (.dll file)? I hate the idea of having someone's .dll in my projects, is it OK to statically link, even for commercial programs? How does static linking work? When I build a library it usually makes a lib file, can I move that lib file anywhere? Is that file the only file I need to use that library in any project?
If linking statically is a bad idea, how do I debug while using a dll? Will code-hinting work with a dll? Using a dll seems almost impossible!
I have had zero success with statically linking, boost, taglib and id3lib. I dont want to try using a dll.

NOTES
- I am on windows 7, I only write for windows
- I use Visual Studio 2010

I have found some tutorials online about linking libraries in VS, but they are usually outdated and use lingo which I don't understand. Any help is welcomed.
Thanks.

[Disch]

First off, what is the difference between static linking (.lib file) and a dynamic link (.dll file)

For starters, it has nothing to do with .lib/.dll. A .lib could be static or dynamic (though dlls are always dynamic)

Dynamic linking makes it so your program loads the library and uses it at runtime. The library is loaded from a separate file (the dll file -- although you would tell VS to link to the .lib file in your project)

It might help to think of dlls as mini-exes. They contained compiled code just like your exe does.

Static linking effectively builds the dll file into your exe so you don't need to load it from a seperate file at runtime.

Advantages for dynamic libs:
- smaller exe size
- multiple programs can share the same dll file(s)

Advantages for static libs:
- fewer dll dependecies

is it OK to statically link, even for commercial programs?

It depends on the license. See the license of whatever library you're using.

When I build a library it usually makes a lib file, can I move that lib file anywhere?

I typically put them in a designated "lib" folder somewhere, and tell VS where that folder is. That way I can easily link to them later.

Is that file the only file I need to use that library in any project?

You'll also need the headers.

And if you're dynamically linking, you'll also need the dll(s).

If linking statically is a bad idea,

It's not. I tend to prefer it for easier distribution. Especially in C++. Dynamic linking doesn't work as well in C++ as it does in C.

how do I debug while using a dll?

There are often debug versions of dlls. Although you don't need to debug code in the dll (not unless it's a dll you're writing) so it's kind of a moot point.

Even if the dll isn't a debug build you can step through your code just fine, no matter how the lib is linked.

Will code-hinting work with a dll?

you mean like intellisense stuff? It usually gets that from the headers, so yeah it will work fine. Remember you need the headers regardless of how you're linking.

[simeonz]

Basically, what Disch said. I want to clarify just a few points (although I am not expert on this).

The compiler works with source code. The linker works with machine code. What the linker does is to basically patch the code together, by dumping the compiled output from the object and library files into your executable and overwriting some address constants here and there.

The linker is language independent. You can write one portion of the code in C++, another in assembly, a third one in Pascal, and the same linker can glue them together into the same executable. As to how this code will interoperate later when it is run is a different story.

Notice also that the intermediate files (.obj .lib) and the output files (.exe, .dll) are essentially in the same format, or at least can be in the same format. To my best understanding COFF and ELF are the two formats that are used for the stuff. COFF is prevalent on win32 I think, and I read that ELF is what's used on Linux.

So, since the linking is language independent, and the format is essentially the same for the linker input and output, why not have linker inside the operating system? As Disch said, this leads to smaller memory consumption, and to smaller executable size. This second linking after link linking is part of the OS loader, which is the code in the OS that launches the programs. And it operates in pretty much the same way - dumps all the necessary code in the memory from the EXE and DLL, and overwrites address constants here and there.

There are other important reasons for the existence of DLLs. I mean, the efficiency stuff is loosing significance these days. First, DLLs allow you to deliver new versions of the DLL without rebuilding the applications that use them. The downside is that you can break the applications in this manner, by shoving them version of the library that they can not handle, and this causes a lot of headache. This is gorier, if some new application requires the new version of the DLL, but the old one dies after the upgrade.

Second, on Linux interprocess communication (two programs communicating together) is facilitated by pipes, signals and such. The first is virtual file in the file system, the second has its own facility in the C++ language as you may know. On Windows, DLLs are frequently used for the same purpose. This can be done, since the memory in the DLL is by default shared by all applications that use it (very different from the .lib). Consequently the DLL can mediate the communication of information between several of its clients (i.e. several programs).

Notice also, that on Linux the distribution of code is mostly done on the source level. So, dependencies on third-party code can be entirely resolved during build-time linking (versus during launching). Linux also has shared objects, which are the equivalent of dlls, but they are not necessary if all components of the software can be deployed and compiled on the user site. This is different from Windows, where much more code is kept proprietary and DLLs as machine code allow a kind of natural obfuscation.

Regards

[Nuclaer]

Very very helpful posts, thank you so much. That cleared up everything :).