|
|
By now you should realize that the computer has to do a lot of work even for simple tasks. Because of that, you have to do a lot of work to write the code for a computer to even do simple tasks. In addition, programming tasks are usually not very simple. Therefore, we neeed a way to make this process easier on ourselves. There are several ways to do this, including:
Write code in a high-level language instead of assembly language
Have lots of pre-written code that you can cut and paste into your own programs
Have a set of functions on the system that are shared among any program that wishes to use it
All three of these are usually used to some degree in any given project. The first option will be explored further in Chapter 11. The second option is useful but it suffers from some drawbacks, including:
Code that is copied often has to be majorly modified to fit the surrounding code.
Every program containing the copied code has the same code in it, thus wasting a lot of space.
If a bug is found in any of the copied code it has to be fixed in every application program.
Therefore, the second option is usually used sparingly. It is usually only used in cases where you copy and paste skeleton code for a specific type of task, and add in your program-specific details. The third option is the one that is used the most often. The third option includes having a central repository of shared code. Then, instead of each program wasting space storing the same copies of functions, they can simply point to the dynamic libraries which contain the functions they need.
If a bug is found in one of these functions, it only has to be fixed within the single function library file, and all applications which use it are automatically updated. The main drawback with this approach is that it creates some dependency problems, including:
If multiple applications are all using the same file, how do we know when it is safe to delete the file? For example, if three applications are sharing a file of functions and 2 of the programs are deleted, how does the system know that there still exists an application that uses that code, and therefore it shouldn't be deleted?
Some programs inadvertantly rely on bugs within shared functions. Therefore, if upgrading the shared functions fixes a bug that a program depended on, it could cause that application to cease functioning.
These problems are what lead to what is known as "DLL hell". However, it is generally assumed that the advantages outweigh the disadvantages.
In programming, these shared code files are referred to as shared libraries , dynamic libraries, shared objects, dynamic-link libraries, DLLs, or .so files.[1] We will refer to all of these as dynamic libraries.
[1]Each of these terms have slightly different meanings, but most people use them interchangeably anyway. Specifically, this chapter will cover dynamic libraries, but not shared libraries. Shared libraries are dynamic libraries which are built using position-independent code (often abbreviated PIC) which is outside the scope of this book. However, shared libraries and dynamic libraries are used in the same way by users and programs; the linker just links them differently.
|
|