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.