Two of the big reasons are quicker compilations and smaller binaries.
So as you know, there isn't any reason why you can't include all the
source files or every program you write and compile it all at once. An
example will show why that would be BAD. Suppose I am a beginning
video game programmer using some fancy graphics library. The very
first thing I do when I sit down to write Doom 4 is to write a skeleton
application that says something like
#include <mygraphicslibrary.h>
int main()
{
MyGraphicsLibrary mainGraphicsObject; //line 1
return 0;
}
and compile it. Normally, you just include the header, compile your
file, and then link an already compiled library of mygraphicslibrary,
and it works and is very fast.
What goes on behind the scene while it's compiling your file is that
the compiler sees the line "MyGraphicsLibrary mainGraphicsObject" and
also sees that the header file says this is legal code (by saying there
is a MyGraphicsLibrary class and saying that that class has a default
constructor). So now the compiler knows there is compiled code
somewhere that will "fit" into the function "holes" in your file that
will make everything work(remember the header typically just says what
code is legal, but doesn't say anything about what that code actually
does or how it works). So what happens is that your file is compiled
in a way that will make it possible to go back and connect up the
missing functions(that connecting is the linking step) Because of this,
to the compiler, compiling that file is about as much work for a
compiler as compiling the file
int main()
{
int x;
return 0;
}
This is because the compiler doesn't have to do anything except know
that some object is created and that linking will provide a pre-written
function to do that. So your program will compile in one or two
seconds. When you link it to the MyGraphicsObject library, the code
you have just compiled says "I need a default contructor for a
MyGraphicsLibrary object" and the library says "I have a default
constructor for a MyGraphicsLibrary object". The linker can quickly
connect the two together and the whole process(compiling and linking)
should take just a second or two.
If, however, you decided to compile the code all at once, you would
probably find that the graphics library is thousands of lines long, if
not tens of thousands. It likely would end up taking hours to compile
your simple program. Additionally, each time you wrote a new program
with this graphics code, you would have to redo this long, long
compilation. I am currently working on a medium sized program that
takes about 40 minutes each time I need to recompile from scratch. If
I didn't link in already compiled versions of the libraries, it
possibly could take days. So speed is one huge reason.
Size is another reason for using shared libraries. So now suppose you
are writing some new string library. And this library is going to be
so great that everyone who writes programs is going to use it. Maybe
you write a couple programs that use this library and you want to know
why you should link this to a shared library or a static library. In a
static library, you compile your string code and then any program that
needs to use that string code basically copies the static library into
it's own space. So each program that you write now includes your
string code and has a larger size because of it. Maybe even more
important is that each program runs its own copy of that string code.
So that's a lot of extra disk space and a lot of extra memory that all
those programs use. The alternative is to link your program to a
shared library. Then each program is able to share the same code. So
the programs all stay smaller(because they use the community copy,
instead of making a copy for themselves). They also use less memory,
because the string code only has to be loaded once, which all programs
then share, instead of loading one for each.
A final reason is for making closed-source code. Supose I owned a
programming company and made graphics libraries that were intended to
be used by other programmers. But I want to keep my code secret, so
that other people can't copy or steal it. So the problem here is how
do I give people code so that they can see exactly what the program can
do without there being any way for them to find out how it does it.
Libraries are the way to do this. I can give you header files(what it
does) and a library file(how it does it), and you will be able to use
the software perfectly, however, you won't know anything about how it
works other than what it does.
Anyways, this was very long, but I hope it helped. Libraries aren't
terrible complicated, but a lot of books and stuff doen't really
explain them all that well and it makes them seem much more complicated
than they need to be. Hope it helped.
