Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!mailrus!uflorida!novavax!twwells!bill
From: bill@twwells.com (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: A solution to the multiple inclusion problem
Keywords: #include c c++
Message-ID: <1989Oct29.171356.9154@twwells.com>
Date: 29 Oct 89 17:13:56 GMT
References: <14240@well.UUCP> <1989Oct23.191634.6345@cs.rochester.edu> <610@wang.UUCP>
Distribution: comp
Organization: None, Ft. Lauderdale, FL
Lines: 35

In article <610@wang.UUCP> mds@wang.UUCP (Marc San Soucie) writes:
: This is not an insignificant issue when file opens are slow, such as across
: some networked file systems. Admittedly compiling across a network is kind of
: goofy, but mature systems shouldn't impose such restrictions on their users.

Well, I don't know.... When I compile programs at work, I haven't
the faintest idea which computer my files happen to be on, unless
I go to some effort to check.

Last time I checked, I log in on proxftl, but my home directory
was on prox04, and my project directories were on prox03.

Oh, and the way we deal with the include problem is this, as has
already been suggested:

In foo.h:

	#ifndef FOO_H
	#define FOO_H
	... stuff in foo.h
	#endif /* FOO_H */

In any include file including foo.h:

	#ifndef FOO_H
	#include "foo.h"
	#endif

We don't bother with wrapping include files in .c files, since
this just makes things harder to read without adding that much
improvement.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com