the pros and cons of "catch-all" header files

  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?

rday
-
To unsubscribe from this list: send the line
"unsubscribe linux-c-programming" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

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 <glynngclements.plus.com>
-
To unsubscribe from this list: send the line
"unsubscribe linux-c-programming" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

Hi Robert

On 8/10/06, Robert P. J. Day <rpjdaymindspring.com> 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.

Goodie !!  I hope this will be as fun for us as it is for
you !!

>
>   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."

I use a similar design architecture in my project.
I think the convinience factor comes in when the project is
REALLY
large and, more impostantly, spread out.

In fact, in my project, I have a a heirarchy of these
"catchall" header files.
Eg. A module has a catchall file for all its sub-modules, A
component
has a catchall header file for all its modules, an interface
for is
components, a product for all its interface and
components.... so on
and so forth.

I can't imagine being selective with the header files as I
would end
up with tens of 100s of LOC of only header file declaration.
Not to mention the tediousness of the selection procedure.



-- 
Raseel.
http://osd.byethost8.com
http://raseel.livejourn
al.com
-
To unsubscribe from this list: send the line
"unsubscribe linux-c-programming" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html