Header files shall not #include any other headers
Steve Ralston
mandate the following:
Header files shall not #include any other headers.
All header files should be #included from each C source file.
I'd like to solicit other opinions, both pro and con on this...
Thanks so much.
Dann Corbit
if it were disallowed.
An *individual* header should be included only once in a file. They can
easily be rendered idempotent to assure this property.
Besides which, lint tells me if I have tried to include a header twice.
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. Newsgroup http://www.dejanews.com/~c_a_p
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm
Scott Fluhrer
Steve Ralston <Steve....@lsil.com> wrote in message
news:38E290E6...@lsil.com...
to include another header file works out much better.
If you don't allow it, then you run into dependancies, for example if you
#include "foo.h", you must always #include "bar.h" first. To #include
"bar.h", you may also need to #include "baz.h". A few files like this is
managable. However, a large program may have hundreds of these
dependancies. Then, consider what happens when you need to add a new module
(or revising an existing module), and have to include "foo.h". If your
internal documentation works exceptionally well, you may be able to find out
that you need to #include "baz.h" and #include "bar.h". If your in the real
world, you don't know that, and if you just #include "foo.h", you'll get
compile errors. To save time, what the poor programmer often does is to
find another module that already includes foo.h, and include *all* the
include files from that one. Do this for a couple of months, and you
quickly reach the point where just about all source files include just about
all include files. At this point, you really are in no different situation
than if you just put everything into a humungous "entire_universe.h" file --
touch a random .h file, and you'll need to remake everything.
I know -- I've seen it happen.
The best thing to do (again, IMHO) is to make a rule that you can #include
*any* include file, and not get an error because of dependancies -- if the
include file needs to reference something from another include file, it'll
include it directly And, you make a rule that you don't include a file
unless you need to reference something in that file.
--
poncho
Lou Zher
news:38E290E6...@lsil.com...
> Some of the programmers in our group would like to
> mandate the following:
> Header files shall not #include any other headers.
> All header files should be #included from each C source file.
>
> I'd like to solicit other opinions, both pro and con on this...
>
I disagree. (My not so humble opinion.)
I perish the thought of having a long long list of includes at the beginning
of each .c file. Not allowing recursive includes also leads programmers to
make superlong all inclusive ones, which is probably the problem you want to
avoid in the first place. Recursive includes allows for better
class-structuring of constants and declarations. It also allows for
inheritance of them, so that user.h could include pdmenu.h, dialog.h,
mouse.h, toolbar.h, etc.. Where, if you just needed dialog.h stuff, you just
include dialog.h, but if you are going to make full, or even nearly full,
use of the user.h stuff, just include that. Plus, it allows the headers to
determine order of includance (a word?). Otherwise, it's up to the
programmer to remember the order for each .c file. Even if dialog.h needs
mouse.h, it can just include it. As long as individual headers check for
multiple inclusion, this shouldn't be a problem.
Example:
-[ User.h ]-
#ifndef _h_user
#define _h_user
#include <mouse.h> // include mouse.h, first inclusion.
#include <dialog.h> // dialog.h includes mouse.h also, but it's
neutered.
#include <pdmenu.h>
#include <toolbar.h>
#endif
-[ Mouse.h ]-
#ifndef _h_mouse
#define _h_mouse
...
#endif
-[ Dialog.h ]-
#ifndef _h_dialog
#define _h_dialog
#include <mouse.h> // neutered double include if user.h was included.
...
#endif
-[ main.c ]-
#include <user.h>
I can see the 'one 2K include' yields 'giant bucket of worms' problem, but
would it really be any different if it was just one 100K bucket-of-worms.h?
-LZ
Selim Levy
>
> Some of the programmers in our group would like to
> mandate the following:
> Header files shall not #include any other headers.
> All header files should be #included from each C source file.
>
> I'd like to solicit other opinions, both pro and con on this...
You're getting my personal programming preference on this...
Unless a header file requires another one, I don't place #includes in my
headers. (It happens fairly rarely that a header #includes another.)
My C source files #include the headers they require, including their own
header file but not by any means *all* the headers. The C source file
containing my main() often doesn't have a header file, since all the
functions in it are only called by the main() function (, such as
usage(), command line argument parsing,...). Of course, I put a safety
latch on my headers so that they don't get included twice... This
method has never given me any problems whatsoever.
Cheers,
Selim
--
"Mille millions de mille sabords!"
Capitaine Haddock
ke...@hplb.hpl.hp.com
Steve Ralston <Steve....@lsil.com> writes:
> Some of the programmers in our group would like to
> mandate the following:
> Header files shall not #include any other headers.
> All header files should be #included from each C source file.
>
> I'd like to solicit other opinions, both pro and con on this...
It's a completely daft idea.
It requires the writer of a C file (translation unit, whatever) to
know and track the dependencies of *all* they header files they
include. Change a header for a library-like file, and *all* the
C files that use it have to change; they have to be edited. This
is a pain.
The header file no longer documents the headers it requires. This
makes inventing a new C file harder, because you know you want
to include "spoo.h" but you've no idea whether and which of "narn.h",
"b5.h", "starfury.h", and "clarke.h" you *need*: they were all
included by the other file ("s4.c") that includes spoo, but you
don't know why. And when you're reading the header, you don't know
which other header files to consult to understand the types.
It might be argued that it reduces compile-time by ensuring that
any header is included exactly once in a .c file, because you
can eliminate duplicates in that file. Perhaps I don't write large
enough programs: it's never been a time-issue for me.
It might be argued that it makes it obvious what include files
are needed (and hence which ones are not). That's what computers
are for. If I want the full list, I look at the makedepend-constructed
part of my makefile(s).
--
Chris "opinion masquerading as opinion" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
Mike Mccarty Sr
for a project to have some private types used in quite a few places, say
a linked list link type, which is embedded in several other structures.
Having one include which is never intended to be included directly, but
only indirectly through other files, is a reasonable way to handle this.
In article <38E290E6...@lsil.com>,
Steve Ralston <Steve....@lsil.com> wrote:
)Some of the programmers in our group would like to
)mandate the following:
) Header files shall not #include any other headers.
) All header files should be #included from each C source file.
)
)I'd like to solicit other opinions, both pro and con on this...
)
)Thanks so much.
)
)
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel <- They make me say that.
-hs-
>Some of the programmers in our group would like to
> Header files shall not #include any other headers.
>
My personnal rule is simple :
My headers are guarded (Like those from the library)
I include a header when I need it. (Can be in a source or a header)
--
-hs- "Stove"
CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
ISO-C Library: http://www.dinkum.com/htm_cl
"It's specified. But anyone who writes code like that should be
transmogrified into earthworms and fed to ducks." -- Chris Dollin CLC
Juergen Heinzl
>Steve Ralston a écrit dans le message <38E290E6...@lsil.com>...
>>Some of the programmers in our group would like to
>>mandate the following:
>> Header files shall not #include any other headers.
>> All header files should be #included from each C source file.
I agree.
>>
>>I'd like to solicit other opinions, both pro and con on this...
[...]
One problem are the dependencies ...
a.h
b.h
c.h
d.h
e.h
f.h
... in a large project. Assume 100 files require a.h, 23 c.h, 43 e.h
and 15 all of them. Now make a change to e.h, start make and go for
a long coffee break as instead of 43 files 143 files are going to
be compiled.
Sure, 100 of them could be ignored, but if you generate the
dependencies via the compiler e.h is going to show up for all
files that include a.h.
Sure, you could generate the dependencies yourself too. It will
drive you crazy in the long run, but it is possible.
Aside from that, it can be quite a hassle to edit a C file, then
opening a.h, only to find that what one is looking for could be
in b.h ... f.h while the final result is g.h which some programmer
forgot to include.
I just hate that.
[...]
>My personnal rule is simple :
>
>My headers are guarded (Like those from the library)
>I include a header when I need it. (Can be in a source or a header)
[...]
Still means all those files have to be opened at least one and this,
too, is going to slow things down. Okay on a one user installation,
but with 20 people crunching along on the same server, well ...
It is true, sometimes one must needs additional includes, but if
not, then it is better to avoid them.
Kind of sprinkling (void *); all over the code. It does nothing
but hey, looks pretty, doesn't it ?
Cheers,
Juergen
--
\ Real name : Jürgen Heinzl \ no flames /
\ EMail Private : jue...@monocerus.demon.co.uk \ send money instead /
Ken Ostaszewski
Juergen Heinzl wrote:
> In article <8c3a23$2klb$1...@news5.isdnet.net>, -hs- wrote:
> >Steve Ralston a écrit dans le message <38E290E6...@lsil.com>...
> >>Some of the programmers in our group would like to
> >>mandate the following:
> >> Header files shall not #include any other headers.
> >> All header files should be #included from each C source file.
>
> I agree.
>
> >>
> >>I'd like to solicit other opinions, both pro and con on this...
> [...]
>
> One problem are the dependencies ...
> a.h
> b.h
> c.h
> d.h
> e.h
> f.h
> ... in a large project. Assume 100 files require a.h, 23 c.h, 43 e.h
> and 15 all of them. Now make a change to e.h, start make and go for
> a long coffee break as instead of 43 files 143 files are going to
> be compiled.
Just a thought, I hope you didn't just include file e.h in file a.h for the
hell of it.
I hope that if you include file e.h in file a.h, you need some interface
information which is contained within e.h for the interface to file a.h.
If that is the case you will need to recompile those files which require a.h
also to make sure that whatever you changed in file e.h didn't screw up
anything in the interface to file a.h.