all.h

[atindrasrs]

suppose my source code is divided into several modules and there are
many header files like a.h, b.h, c.h, d.h. It is possible that one .c
file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
dependencies. In such a case, is it better to have a single header
file "all.h" like this -

all.h

#include "a.h"
#include "b.h"
#include "c.h"
#include "d.h"


Then include this all.h in all the .c files ??

 

[Harald van Dijk]

suppose my source code is divided into several modules and there are
many header files like a.h, b.h, c.h, d.h. It is possible that one .c
file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
dependencies. In such a case, is it better to have a single header file
"all.h" like this -

all.h

#include "a.h"
#include "b.h"
#include "c.h"
#include "d.h"


Then include this all.h in all the .c files ??

That depends. This way will save you on typing initially, but when you
want to add #include "e.h" to all.h, you have to check all of a.c, b.c,
c.c, and d.c, to make sure it doesn't conflict with any of them. And if it
does conflict, you can't just leave it out, you have to update the .c
files. If you think this might be a problem, use the more explicit
version. If you don't, pick whichever you like best.

 

[santosh]

suppose my source code is divided into several modules and there are
many header files like a.h, b.h, c.h, d.h. It is possible that one .c
file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
dependencies. In such a case, is it better to have a single header
file "all.h" like this -

all.h

#include "a.h"
#include "b.h"
#include "c.h"
#include "d.h"


Then include this all.h in all the .c files ??

This method won't scale well to large projects. If you eventually end up
with dozens of headers, compilation time is going to come down to a
crawl.

Include in each .c file only the headers that it needs. This is the best
way from long term maintenance POV and also makes you think and review
things at each modification.

The "include all headers" method is okay for small or perhaps medium
sized projects, but will get out of hand for large ones.

For example, can you imagine each .c file in the Linux kernel or in gcc
or in glibc including every header in the source base? Think of the
mess.

 

[Ian Collins]

suppose my source code is divided into several modules and there are
many header files like a.h, b.h, c.h, d.h. It is possible that one .c
file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
dependencies. In such a case, is it better to have a single header
file "all.h" like this -

all.h

#include "a.h"
#include "b.h"
#include "c.h"
#include "d.h"


Then include this all.h in all the .c files ??

There is a possible benefit if your tools support precompiled headers.
Otherwise you will create too much coupling, changes to a header x that
is not used by source file y causing y to be recompiled.

A compromise if your tools support precompiled headers is to group
together a subset of commonly used headers in one file to improve
compile times.

 

[CBFalconer]

suppose my source code is divided into several modules and there are
many header files like a.h, b.h, c.h, d.h. It is possible that one .c
file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
dependencies. In such a case, is it better to have a single header
file "all.h" like this -

all.h

#include "a.h"
#include "b.h"
#include "c.h"
#include "d.h"

Then include this all.h in all the .c files ??

I believe not. I consider the best means is to provide one .h file
to go with each .c file, specifying the access to that code
allowed. You can also have some specialized .h files to establish
some constants, etc.

Now you can arrange to only include the necessary areas in each .c
file (including its own .h file). Note that this way each .c file
indicates what other files affect it.

You still have the option of building some big subsets by writing a
..h file that simply specifies:

#include a.h
#include b.h
#include c.h
... etc ...

but that is only for your convenience.

 

[Scott S. McCoy]

suppose my source code is divided into several modules and there are
many header files like a.h, b.h, c.h, d.h. It is possible that one .c
file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
dependencies. In such a case, is it better to have a single header file
"all.h" like this -

all.h

#include "a.h"
#include "b.h"
#include "c.h"
#include "d.h"


Then include this all.h in all the .c files ??

Don't be lazy, just type the includes. It's not that big a deal. Plus
it'll help you keep a handle on circular dependencies and similar things
that are generally bad.

 

[Ed Prochak]

suppose my source code is divided into several modules and there are
many header files like a.h, b.h, c.h, d.h. It is possible that one .c
file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
dependencies. In such a case, is it better to have a single header
file "all.h" like this -

all.h

#include "a.h"
#include "b.h"
#include "c.h"
#include "d.h"

Then include this all.h in all the .c files ??

NOoooo! It is not better.

Just consider two modules, A and C that happen to define functions of
the same name, foo(), or macros of the same name, or any other
possible collisions.

When such collisions happen, it is not pretty because it does not
always cause a compile error. IOW, it blows up at runtime. Not fun. So
NO not good practice.

Ed

 

[Ian Collins]

NOoooo! It is not better.

Just consider two modules, A and C that happen to define functions of
the same name, foo(), or macros of the same name, or any other
possible collisions.

When such collisions happen, it is not pretty because it does not
always cause a compile error.

It should.

 

[GMM50]

suppose my source code is divided into several modules and there are
many header files like a.h, b.h, c.h, d.h. It is possible that one .c
file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
dependencies. In such a case, is it better to have a single header
file "all.h" like this -

all.h

#include "a.h"
#include "b.h"
#include "c.h"
#include "d.h"

Then include this all.h in all the .c files ??

If you're going to have a large complicated project then I've found it
best to keep separate c and h files. Why did you divide your code
into several c files. Probably to keep it organized better. So that
seems to indicate you'll be better served with separate h files.

Let's say your project is up and running, time has passed so you not
so close to your code and you need to make a small change. I thinks
it's better to keep that change isolated to individual modules say a.c
and a.h.

Even if you have to make a large change. Say you can't purchase a
component that is part of your system and need to change to another
with different interface characteristics. Again separate modules
would seem to me to be better.

If you have a simple project then perhaps one c file and no h files
would be better.

my 2 cents.

george