Robert P. J. Day wrote: > over the next few days, i'm going to have some general design-type > questions as i try to restructure a project i'm working on, so i'm > hoping i don't wander too far from the mandate of the list. > > on this current project, there is frequent use of what i call > "catchall" header files. rather than have individual source files > pull in just those header files they need, a monster "catchall.h" file > is created that contains almost all project-related inclusions, so > that source files need only: > > #include "catchall.h" > > sure, it's convenient, but there are also some obvious downsides. > the simple question -- is there a defensible rationale for this > approach? i personally don't like it and would prefer source files to > be more selective, but the argument i keep hearing is, "it's more > convenient." > > thoughts? The pro is that it's convenient. The con's are that it might include too much, e.g. introduce type or macro names which conflict with identifiers which your source files use. How much of a problem this is depends upon how "clean" the header is. Including system headers, defining (as opposed to declaring) variables, and leaving parameter names in function prototypes will all create additional problems. Also, a single large header reduces modularity, and makes it harder to re-use distinct subsystems from the code. -- Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx> - : send the line "unsubscribe linux-c-programming" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
