best size of a c module

[Jim Marshall]

Brian Dessent wrote:
> 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.
Wow - that shook a lot of cob webs in my head, but that is exactly what 
I recall now.

> 
> 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.
Good information.

Thanks for taking the time to respond!

-Jim
> 
> Brian
>