Jim Marshall wrote: > Many, many years ago whilst working in DOS I recall reading something > that indicated the best size for a c file was about 4 or 5K. I have no > idea if that was true or not, but I was looking at some code the other > day and it was a fairly large .c file. So I was wondering if there is an > optimal size for c modules on todays Linux machines. I think part of the reason for this advice was back in the 16 bit dark ages of MS DOS there were no shared libraries and all code was statically linked. By the design of most linkers, when statically linking the level of granularity is at the object file. In other words, if it determined that any symbol in foo.o was needed, all of foo.o was copied into the final link output. Therefore there was a distinct advantage in terms of final code size to put as little as possible in each .c file -- ideally only one function per file -- since this meant as little dead code in the output as necessary, particuarly for large libraries. Now that we're in the modern era we use dynamic linking whereever possible which pretty much eliminates this concern entirely, though you may still find libraries that are designed with one function per .o file because they still might be built statically, especially system libraries. In fact in the modern era it can almost be more advantageous to put more in a translation unit rather than less, especially if you mark static functions as such, because it allows for inlining and better unit-at-a-time optimizations. So I would definitely caution that this advice is certainly bunk now. It's definitely true that you want to keep the size of functions down, because very long functions are hard to follow, not to mention indicative of bad design. It's also true that lumping everything into one .c file is bad design since it encourages a lot of global state and little thought to proper interface design, separation, and layering. But these are more kinds of "art of the craft" type suggestions, not "do this because the tools work better this way" technical limitations. Brian
