If I make a library of functions to use in other programs that I want to be compiled now to save compile time in the future, is it better to use a .dll file, or a .lib file to have the functions in?
Printable View
If I make a library of functions to use in other programs that I want to be compiled now to save compile time in the future, is it better to use a .dll file, or a .lib file to have the functions in?
It is better to use DLL since it will be linked dynamically. If you change functions inside DLL without changing the interface of the functions, you need not recompile EXE files (which depends on the DLL). For LIB, files, since it will be linked statically, you need to recompile it for every change.
You may like to read the DLL chapter on this book.
http://www.enselsoftware.freeservers.com/compprog.html
same kind of sematic overloading:
[quote]
Although the photographer and the art thief knew each other for quite some time, neither had ever taken the other's picture.
[/code]
Or self-referential structures like:Quote:
Time flies like an arrow
Fruit flies like a banana.
Quote:
This sentence no verb.
:D
same kind of semantic overloading:
[quote]
Although the photographer and the art thief knew each other for quite some time, neither had ever taken the other's picture.
[/code]
Or self-referential structures like:Quote:
Time flies like an arrow
Fruit flies like a banana.
Quote:
This sentence no verb.
:D
What if you have any inline functions in your interface?Quote:
Originally posted by sbasak
It is better to use DLL since it will be linked dynamically. If you change functions inside DLL without changing the interface of the functions, you need not recompile EXE files (which depends on the DLL). For LIB, files, since it will be linked statically, you need to recompile it for every change.
You may like to read the DLL chapter on this book.
http://www.enselsoftware.freeservers.com/compprog.html
I say use .lib every time, a lot easier than a DLL (no more DLL hell :p).
same kind of semantic overloading:
[quote]
Although the photographer and the art thief knew each other for quite some time, neither had ever taken the other's picture.
[/code]
Or self-referential structures like:Quote:
Time flies like an arrow
Fruit flies like a banana.
Quote:
This sentence no verb.
:D
I think Jim's finally lost it...years of programming have taken their toll and he's been reduced to posting junk messages on a web forum.
Umm...oops...didn't take too long for me :D
What exactly is DLL hell?
Also, can someone list the pros and cons of .libs and .dlls? There don't seem to be any sites that do :(
.libs and .dlls are very simlilar. It's just a question of where you want the functions in the library to be when you have compiled your exe.
If you want those functions to be in your exe, use a .lib (statically linked library - linked at compile time).
If you want those functions to be in a seperate library, use a .dll (dynamically linked library - linked at run time).
.libs are probably easier to work with overall.
The main reason to use .dlls is so you can share compiled code between different programs on the same machine that use the same library functions.
LIB
A file that contains code and a few hints for the linker. When a lib is linked to an exe or a dll, the linker seeks the used functions and copies them to the exe/dll. It's basically a pre-compiled code snippet library.
+
Fast function calls, the functions are copied directly to the exe and are maybe even inlined.
Easy to create.
-
Makes exes bigger.
The same code may be in memory several times.
DLL
A complete executable module that contains code, loader info and resources. When an app needs a function, it can either look it up and directly call to the address or use the stubs from an import library.
+
Eliminates redundant code. Imagine every app in windows had it's own copy of the WinAPI in memory!
Can be changed without having to recompile every associated app.
Resource DLLs can simply be replaced to localize an app.
-
Function calls take a little longer.
Several programs could use different versions of a dll, thus creating the "DLL hell" parksie mentioned.
More administration for windows.
So, DLL hell is basically having two programs that require different versions of the same DLL?
Pretty much, yeah. It usually manifests itself as you have some programs that work fine, then you install another one that updates the DLL, breaking half the others.
This is part of what WFP (Windows File Protection) is designed to prevent. But even if it breaks your newly-installed app, you can sort it out. All you need to do is put the required DLL that's newer into the program's local directory, and make an exename.local file - doesn't have to have anything in it, but Windows looks for the file.
I think it applies to 2000/XP only, though.