Organizing Large C Programs
cse.shirazu.ac.ir
cse.shirazu.ac.ir
How you organize million line projects is an interesting topic. Does anybody have any actual links?
Large Scale C++ Software Design by John Lakos is about that topic. Of course, C++ is its own special hell when it comes to physical coupling because of what tends to go (and sometimes has to go) in header files.
It's not a terrible book when considering the lack of alternative sources for the material covered, but a lot of its suggestions are showing their advanced age and were dubious and controversial even at the time of writing. Nowadays you have to take into account precompiled headers, unity builds, distributed build clusters, etc, when considering trade-offs in physical design for large code bases.
Free startup idea: Incredibuild in the cloud! Tell us how how fast you want your code base to build and you got it! You'd have to design and implement finer-grained distributed compiling and linking to overcome Amdahl's Law speed-up barriers and make it really competitive with something like Incredibuild for larger companies. But you could bootstrap it with coarser-grained distribution (distributed compiling at the file granularity but with non-distributed monolithic linking) a la earlier versions of Incredibuild while targeting smaller development shops without a lot of spare CPU cycles floating around the office. Making it dead simple to drop in and use with existing code bases would be key.
C++ techniques don't apply to C only projects that often.
Many many many C++ users act like we just don't know C++ or something when use C in systems programming instead of C++, and assume "We just need to upgrade to C++" or the whatever.
If a book only had C++ techniques, it wouldn't be speaking to the topic of this post (which is large scale C programming)
And the comment at the same level at the guy who knows the author directly speaks to how it ALSO applies to C, showing the relevance of your post to the topic
I wasn't being flippant
- The handle-body idiom loosens physical coupling but adds immense overhead to both time and space. For many applications in C++'s domain this is simply unacceptable, full stop. Applying the idiom ubiquitously would mean throwing out most of C and C++'s advantages for programmers in my kind of work.
- For real-time applications (soft or hard), it is important that the performance delta between debug and release builds is kept to a minimum, so you can use effective tools to debug a reasonable facsimile of the application in its final shipping form. This has numerous corollaries. For example, if member function definitions are generally put in .cpp files rather than header files to reduce physical coupling, then you get no cross-module inlining except when expensive, debugging unfriendly and incremental rebuilding unfriendly optimizations like link-time code generation are enabled. In principle, C has the same problem. But in practice, C++ programmers tend to use lots of small function definitions that each do a small amount of work and then defer to other functions. That style of coding depends on aggressive inlining for good performance; it's common to see a much, much larger performance gap between debug and release mode performance with C++ code bases than with C++ code bases for video games (which is what I know best).
In my experience, managing C projects becomes frustrating pretty fast but maybe that's a problem with all languages (most of my limited experience is in C).