OSDev.org

I was wondering if there is any advantage in having individual functions in their own .c files.
Fo e.g. if I had string.h with the functions strcmp(), strcpy, etc... would there be any advantage in implementing these functions in their own respective .c files, say strcpy.c strcmp.c ?

1) Why we split our code in .c and .h

Sure you could write each code module in a .c file, and simply concatenate them together for the compile. But sometimes functions are mutually dependent, and you would get warnings for using a function without declaring it first. You also would have to pay great attention to declaring the data structures and constants in the correct order.

Thus, it is much easier to split up a code module into a .h file (containing declarations) and a .c file (containing definitions). The .c file includes its own .h file, and voila, sequence of definition doesn't matter anymore because everything has already been declared.

Another point is that you sometimes want to use binaries only. (OSS people please don't cry bloody murder, you're not recompiling the C library for each application, either.) In order to correctly use the interface of that binary module, you need the header.

2) Why we split our code into multiple .c files

Modularity, maintainability, brievety of the individual source file. You want your file handling code in one place, your UI code in another, the algorithms in yet another. Lumping everything into a single C file makes things rather unwieldly.

And then, you'd have to recompile everything no matter how small your changes were. With sources split up among several .c files, you only have to recompile the changed one, and re-link the object files.

3) Why, especially in a standard library, it can be worthwile to split code into one file per function

When you're working on an application, in the very end you'll have one big executable anyway. Things are a bit different if you're doing a function library (like PDCLib).

If you had only one .c file for all of, for example, string.h, your application would get all the code for all of string.h linked in the very moment you use but a measly strcpy(). (For PDCLib, that'd be 1726 bytes instead of the 61 bytes of strcpy() alone). If you have one .c file per function, this allows the linker to drag in only the functions you really use.

4) Having one function per object file allows a little trick - you can add a (conditionally compiled) [tt]int main()[/tt] to each function's .c file, containing a test driver for that special function - i.e., you can compile to library object file or test driver executable with the flick of a compiler switch. A nice added bonus.

Thanks Solar. I was thinking of the standard libs when I asked this.

I was wondering if this would be suitable/efficient for app/OS deving or too much of a headache maintaing them like this?

Nice to know of that "trick" too.

Neo wrote: I was wondering if this would be suitable/efficient for app/OS deving or too much of a headache maintaing them like this?

Actually, I think it is much easier this way, having one file per function, than it would be if I had grouped several functions together.

Oh, one thing I forgot that's specific to PDCLib: With one file per function, you can easily replace individual files with implementations of your own, simply by copying your "patch directory" over the source tree. No need for juggling with diff / patch.

Solar wrote: 2) Why we split our code into multiple .c files

Modularity, maintainability, brievety of the individual source file. You want your file handling code in one place, your UI code in another, the algorithms in yet another. Lumping everything into a single C file makes things rather unwieldly.

You would if you wanted it to be maintainable. I now know what code looks like that wasn't designed to be maintainable, containing a total of 3 files with real content (>2k), which then have an average filesize of 100k. Having 4 company names back + 1988 at the top doesn't help either.

For comparison for yourself, look at TinyCC (iirc), it's a single 180k C file.