The Zen of Libraries (Part III) Empower yourself: use Libraries
Copyright Notice
Copyright: Ramesh Ananthakrishnan 11th May 2003
Pilfer at your own Peril
Introduction
If you have read the previous two articles, you’d like to now probably use libraries whenever you
program and are looking for some general hints. Well… I’d like to empower those people
who are still stuck with Turbo C and also help those who are using gcc on Linux and scratching
their head over what to do. So the article will focuss on these two specimens.
Rule 1: Search Google for Libraries that already do your job
For any given project there exist libraries that do around 70 % of your work. Use them. The major
problem is that most people are hardly aware these libraries exist. Hence they end up
reinventing the wheel. Also make sure that you can compile the libraries on Turbo C or with
gcc, and make sure that those libraries don’t depend on other libraries, (this condition
is also known as dependency hell) something I’ll come back to later. Once you get your libraries
make sure that you also download the headers for the library. Remember before you call a
function the function has to be defined. The header files contain the definition so please
use that. Without the header file you are in deep shit! So remember to download both the
library and the headers. And please search google atleast 10 times with different queries.
Rule 2: Divide your work into libraries
Divide your work to be composed of different libraries. E.g. : If you are writing an Audio
player, divide it into the following libraries. One to actually interpret the File and
give you raw data to be fed into the speakers. One to control the speaker volume, one to
draw the buttons on screen. Once you divide the stuff like this, you’ll find out that
you can actually search google with exact terms, and find libraries that do what you want.
Test each of these libraries separately. This makes for easy development. It’s easier to
test and debug 2 files with 100 lines of code, than to test and debug one program with
60 lines that calls the 2 files with 100 lines of code each abt. 35 times individually.
Do unit testing.
The Golden Rule: Once you start writing the main loop don’t touch your libraries
This is the most important rule and one that requires iron discipline. If you cannot touch
your libraries once you start writing main, all your libraries should bloddy well do whatever it
is that you require of them. This forces you to think about what your libraries should do,
and forces you to clearly indicate the requirements of your library and this saves you a lot
of effort later on. Believe me abt. this!
HOWTO 1: How do I start making a library ?
Simple. If say you write string handling functions. Then divide it into a header file say…
my_string.h that should contain only function definitions or macros. Only include definitions
that you need to use. E.g. If you have a function that reverses the string but you are never
possibly going to need in you project do not define it in your header file. Write the entire
function out in the C file. The body of all the functions should be in the associated C file.
REMEMBER: ONLY STUFF YOU NEED TO ACCESS MUST BE IN THE HEADER FILE. FUNCTION
BODIES IN CPP FILES. AND ALL OTHERS MUST BE PLACED ONLY IN THE CPP FILE.
HOWTO 2: How do I compile it into a library?
Once you have the header and the cpp file.
In Turbo C : Make a new project with an appropriate name. Add your header and Cpp file to
it. In fact copy them both so that they are there in the same directory. Modify your
include directories and source dierectories so that the whole thing works. Now change the
exe type from the menu from standard exe to shared library. Compile now. Two files will
be generated, an obj file and an lib file. If your files were called say my_string.h and
my_string.cpp then the library will be called my_string.obj and my_string.lib. These are the
files you want.
In Linux : If your files are my_string.cpp and my_string.h type in
gcc -c my_string.cpp -I./ and the output will be a file my_string.o .
This is your library file.
HOWTO 3: Great. How do I now use it in my program
In Turbo C: Now let’s say your main file is string_main.cpp You have included
my_string.h from this file. Open a new project say string_main.
Modify the include paths so that the compiler can find my_string.h.
Now include in your project my_string.obj and string_main.cpp in your project. Now compile
and link. The output will be an executable like string_main.exe that has the features in
my_string.cpp. You can use my_string.obj in as many projects as you want and never need to
compile my_string.cpp ever ever again.
Congrats!!! You have just used a general purpose library in your programs.
In Linux :type in gcc string_main.cpp my_string.o . The output
is an executable a.out. That’s it. Linux rocks man!!!
HOWTO 4: But this library says it depends on another library
Just like you can make an executable using a library. It’s possible to make a library
using another library. The only way to solve this is to locate all versions of these libraries
your library depends upon download them their headers and compile compile compile till your
application works. Also make sure that your library is compiled for your platform, OS and with
the versions of dynamic libraries present on your system. Downloading a library compiled
with VC 5.0 with MFC build 3.1 and expecting it to work on a Linux box is so naive I have
to warn you against it. Ask the questions: Is it for my platform? my set of libraries? my
compiler? my machine?
If you still can’t work it out please move over to Perl or Python
HOWTO 5: I changed stuff in my library but the program isn’t changing
Remember, most libraries are statically linked. If that’s the case once you change
your library you have to recompile your program. Write Makefiles to ease these situations.
What’s a Makefile? Wait for my article on “The Zen of Make”. If it’s dynamically loaded
make sure that the path is right. And if all this fails switch to Perl.
May 11th, 2003 - Posted in Uncategorized | | 0 Comments
The Zen of Libraries (Part II) Inside Stuff
Copyright Notice
Copyright:Ramesh Ananthakrishnan 6th May 2003
Pilfer at your own Peril
But what type of alien is it? And whence did it come? And what news does it bear?
And is it chocolate flavoured?
—Monty Python
Introduction
In the Zen of Libraries (Part I) you saw why it was necessary to use libraries. This
explains the inside stuff on libraries… but beware! you need to know about assembly,
and a little about operating systems for this to make sense
Assembling the assembly
In order to make this article short, I’ll assume that you all know what assembly is, how it’s
generated from mnemonics. I’ll also assume that you know that the compiler builds a parse tree
and that you know that the next stage is when the compile tree is interpreted to emit assembly
code. In fact if you had the right tools, you can actually see the assembly instructions involved
in the simplest program like the quintessential “Hello World” program.
Also I’ll assume you know abt. offset & segment addresses.
So since we know that an exe is composed of straight assembly what is a library composed of.
Well… the same assembly instructions. In fact the difference between exe’s and libraries is
very simple. It is this:
While libraries do not have any start instruction, all exes have a standard start instruction
and address.
What do I mean by that? Whenever you run a program. the OS actually copies your program into
memory and then, asks the processor to jump to a specific address where your program is loaded.
In fact when your program is compiled “offset” addresses are generated. The starting address
for an exe is a standard offset like say 42 bytes from the start of the program.
Once the program is loaded into a segment in memory, the OS
instructs the processor to perform a long jump to the segment (known to the OS) + offset start
address (which is common to every executable in the OS).
So if your OS loads your program right after the 16th KB. Then the processor jumps to
16KB + 48 bytes. Here there are instruction on what to do next. So the executable can be
say… executed. (Well that’s not the entire story… read Stallings for a more complete
description)
But what about a library???
Libraries are dummies
Since some functions are used by a large number of programs, (think printf) these functions
are already compiled into assembly and kept in library files. So whenever you call say
a printf instruction the linker copies the exact assembly instructions from the library
and inserts it into your program. So a library does not have a start address, it’s just a
collection of useful functions. When programming, keep in mind that you are simply gathering
all these library functions and giving them some dierection under main. So if you don’t have
a main function all you have to do is compile your cpp file and you have a library all
toasty for you to use.
Think of a C library as just the same as a library of books. If you have a purpose
like a term paper, you have a sort of idea of which books you want to read. You go in
pick those books, copy some stuff from it, add some of your stuff to it, and form a term paper.
That’s what programming is all about. The term paper is like your program. It has a structure
to it, the same structure which is given to an executable by the main function. Now your
profs. can read and make sense of your term paper/program. However just giving your prof.
a library full of books as a term paper doesn’t make sense. He may as well write the term
paper himself. What he wants is some stuff extracted from the library, some stuff you have
written that makes a term paper he can understand.
Shared & Static libraries
Just imagine a term paper in which all you guys xerox around a 100 pages of the Java complete
reference API and submit to your professor. Isn’t that a terrible waste of paper. Well, long time
ago when disk space was precious, it was (still is) asinine to copy the printf assembly
instructions into every tom, dick and harry’s program. This lead to the concept of shared
libraries. This means that instead of everyone xeroxing the 100 pages, all of you would write
a small instruction in your term paper like say:
Look at The Java Complete Reference pg. 123
and the prof. would actually do this. This assumes that the prof. also has a copy of the
Java Complete Reference. This is what shared libraries are. In Turbo C the graphics libraries
are shared, so the instructions to draw on screen are not copied into your program.
Turbo C assumes that all machines have a copy of the Turbo C graphics library on their machines.
So when you run a graphics program the graphics library is first loaded into memory.
Then the OS notes where exactly all the graphic functions are in memory. Now when
a call to say… putpixel is made, the OS takes charge figures out where putpixel
is and then instructs the program to jump there. Like all else the above
description is a major simplification. For a detailed nuts & bolts view, look up Stallings.
But is that all…? and How do I use libraries….?
Well not exactly. Libraries are a large, large subject. Since their a little
high level most books that deal with programming languages don’t teach you
anything about it. The books that deal with OS internals and high level stuff like
that don’t deal with it because they assume that by the time you are reading OS books
you already know the zen of libraries. To compound the fact most buggers who CS nutcases
may know their algorithms, but fail to understand the basics abt. libraries. Which is why
I wrote the previous two articles. But how do I use libraries?? you ask. Fear not!
Read Part III of the Zen of Libraries on howto use libraries in your code.
May 11th, 2003 - Posted in Uncategorized | | 0 Comments