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 =?UTF-8?b?RMSzaw==?=]

On Sun, 09 Mar 2008 00:01:45 -0800, atindrasrs wrote:

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]

at********@gmail.com wrote:

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]

at********@gmail.com wrote:

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.

--
Ian Collins.

[CBFalconer]

at********@gmail.com wrote:

>
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.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Scott S. McCoy]

On Sun, 09 Mar 2008 00:01:45 -0800, atindrasrs wrote:

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]

On Mar 9, 8:01 am, [e-mail] wrote:

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]

Ed Prochak wrote:

On Mar 9, 8:01 am, [e-mail] wrote:

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

It should.

--
Ian Collins.