Path: utzoo!utgpu!watmath!clyde!att!osu-cis!killer!ames!mailrus!uflorida!novavax!twwells!bill
From: bill@twwells.uucp (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: C Style
Message-ID: <319@twwells.uucp>
Date: 11 Jan 89 14:06:48 GMT
References: <2688@ficc.uu.net>
Reply-To: bill@twwells.UUCP (T. William Wells)
Organization: None, Ft. Lauderdale
Lines: 44
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <2688@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
: I have been told that the following mechanism for handling nested includes
: is unreliable and/or unportable, but for the life of me I can't see how:
:
: graphics.h:
:       #ifndef GRAPHICS_H
:       #define GRAPHICS_H
:       ...
:       #endif
:
: windows.h:
:       ...
:       #ifndef GRAPHICS_H
:       #include GRAPHICS_H

(Presumably you mean #include "graphics.h".)

:       #endif
:       ...
:
: menus.h:
:       ...
:       #ifndef GRAPHICS_H
:       #include GRAPHICS_H
:       #endif
:       ...
:
: Now this allows a programmer to include windows.h and menus.h, without
: having to (a) know they need to include graphics.h, and (b) worry about
: graphics.h being included twice.
:
: What's wrong with this picture?

Not a thing. The company I work for does this routinely.  Our source
code is ported all over the place (70+ different systems for one
customer alone!) and we've never had a complaint about this.

Strictly speaking, the #ifndef's in the other include files aren't
necessary but they do save on the time needed to skip the useless
files.

---
Bill
{ uunet!proxftl | novavax } !twwells!bill