Structure pointer question

[Michael T Sullivan]

In article <718 at vsi.UUCP>, sullivan at vsi.UUCP (Michael T Sullivan) writes:
> Which brings up a question:  is it considered a good thing or a bad thing
> to have .h files #include'ing other .h files instead of having the .c files
> do it all.  The rule around here is that there are to be no #include's in
> .h files we write.  Mail me your opinions for or against.

Thanks to the many people who responded.  I've had quite a busy mailbox
this past week.

The majority of replies said that if a .h file depends on another .h file,
then the #include should be in the .h file so the .c files don't have to
worry about figuring out the interdependencies.

What to do to avoid accidentally #include'ing a .h file twice?  You do this
by clever usage of the pre-processor:

/* header.h */
#ifndef	_HEADER_H
#define	_HEADER_H	1

#include	"something.h"

...stuff...

#endif	/* _HEADER_H */

(This same arrangement is in something.h)

This will allow file.c to #include header.h only, as well as #include
something.h before header.h without any problems.  Note the leading
underscore in the name-macro _HEADER_H.  This keeps your namespace from
being polluted.

This type of thing sure would be handy in the Unix header files (hint, hint).
Thanks again for all replies.

-- 
Michael Sullivan			{uunet|attmail}!vsi!sullivan
V-Systems, Inc.  Santa Ana, CA		sullivan at vsi.com
ons, workstations, workstations, workstations, workstations, workstations, work