C - breaking code into separate files

Question

When I write code for my small projects, I usually end up with small bits of reusable code which I'll include in future projects. What I have been doing with these is saving them in .h files and using a standard naming convention throughout that file. For example, my code for reading and writing bitmap files is called KBMP.h and every structure and function name is preceded by "KBMP_". Over time, I have collected several of these files which I use in my projects on a regular basis for tasks such as hashing, matrix manipulation, graphics rasterizing, noise generation, etc. When I create a new project I drag in copies of these files and #include them. My impression is that while this gives the modularity I want, this is really, really bad coding practice. What should I do instead? I know there has been a similar question on SO but it doesn't quite answer my situation.

Answer 1

The usual way would be to make a library, either static or dynamic at your choice. The advantage of a dynamic library is that if you change or improve the functionality of any of the functions, all your programs you previously linked to it will automatically use the new version. The principle disadvantage is that if you change the interface, you'll either have to (1) go back and change and recompile all your old programs that use the interface which changed, or they'll stop working, or (2) you'll have to go to the trouble of making different versions of your library to avoid that problem.

You also have a choice as to how many libraries you make. Certainly you wouldn't want to put each function in its own library. Conventional wisdom says that libraries ought to be coherent, and all the functionality in one ought to be related in some way, but you don't have to look any further than the C standard library to find one that's got all kinds of random stuff in it. If this is for your own purposes only, you may as well just dump it all into one, or have one library for all the graphics functionality, another one for the math functionality, and so on.

Even if you only have one big library, you can have different headers for related functionality, in exactly the same way as the C standard library works, so you don't have to pollute your program's namespaces with every single identifier that ends up being declared in the interface to your library.

Answer 2

I have a main library of similar code, built up over the last quarter century. Some files get used in almost all of my projects; others are used in only a very few. They all end up in my library, with the headers in my include directory. The library is not big enough that I worry about the overhead of using static linking, so I only have static (ar) libraries.

When I need to build a project, I build for my development purposes using my installed library. When I distribute the code, I have a release system that collects the relevant library source (and headers, and test code if appropriate) as well as the per-project code into a releasable tar ball.