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

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

[Robert P. J. Day]

  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

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

[Raseel Bhagat]

Hi Robert

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

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

[Glynn Clements]

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@gclements.plus.com>