Suppose you've written a few general purpose functions that you could use in all sorts of programs that you might write. The simplest approach would just be to copy and paste the function into each new program. But this is wasteful and error-prone (not to mention introducing replication—if you found a bug in such a function, you'd have to search for every place you'd used it, change it there, and recompile).
A better technique, and the standard one, for making the function available to other programs without reproducing it every time, is to use the library feature of the compiler. This involves compiling a source code file containing functions (the ones you want to make available), but no main() starting-point. This source file is compiled with cl to create an object file, but linking is not performed—in fact, you can't link it because that would create a program file, which won't be possible given that there is no main().
In order to use the functions in the library file, you
the source file. Traditionally, you include only a header (.h) file rather than
the main source file. For linking, you specify the name of the object file in
the link command line. Obviously, the header and object files must be in a
location that can be found by cl and link. A simple way to do this is to create
a directory for your library files (typically divided into subdirectories called
Include and Lib).
A makefile rule for creating a library file might look something like this:
lib.obj: lib.c lib.h "$(PF_32)\cl.exe" /c /W4 /nologo /I $(INC_VS) /I $(INC_SDK_SH /I $(INC_SDK_UM) lib.c copy lib.h $(INC_MINE) copy lib.obj $(LIB_MINE)
Here, we're creating a library file called lib.obj, which is dependent on lib.c and lib.h, and then automatically copying the new version to my library directory.
Functions that are provided by header/library files can be linked either statically or dynamically. Statically linked functions have their object code added permanently to the executable file. In contrast, dynamically linked functions are not added to the executable; instead, the linker adds a special reference to the associated DLL file, which can then be retrieved when the program is actually running. The advantage is that the executable program is smaller, and the disadvantage is that the operating system must be able to retrieve the DLL file.
Thus, by using the default of static linking, you don't need to consider whether the DLL is available on your user's computer, and the function call might be a bit faster (the execution jump is simpler), but these differences might be negligible due to optimisation techniques like cacheing and so forth. If you use a lot of library functions, then your executable file might be very large because it has to contain all the linked functions. The choice is yours, and will presumably be dictated by the circumstances in which your program runs.
Note that if you link to any library files, they must have been compiled with the same dynamic/static option as the one used for the object file to which they are being linked.
To make it easy to identify the linking type used to create an object
file, you can add a suffix to the object file's name. This can be done by
/Fo option, which allows you to specify the name
of the object file it creates. Thus,
cl.exe /MD /Folib_d.obj
will create a dynamically-linked object file called lib_d.obj, and
/Folib_s.obj will create a statically-linked object file called lib_s.obj.
|Home||About Me||Copyright © Neil Carter|
LAST UPDATED: 2016-03-28