Path: utzoo!attcan!uunet!vsi!sullivan From: sullivan@vsi.UUCP (Michael T Sullivan) Newsgroups: comp.lang.c Subject: Re: Structure pointer question Summary: Summary of replies Message-ID: <723@vsi.UUCP> Date: 20 Jun 88 15:56:33 GMT References: <361@teletron.UUCP> <8074@brl-smoke.ARPA> <718@vsi.UUCP> Organization: V-Systems, Inc. -- Santa Ana, CA Lines: 40 In article <718@vsi.UUCP>, sullivan@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@vsi.com ons, workstations, workstations, workstations, workstations, workstations, work