Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!purdue!decwrl!sgi!arisia!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.c++
Subject: Re: Including header files minimally.
Message-ID: <752@quintus.UUCP>
Date: 27 Nov 88 05:01:47 GMT
References: <3561@pt.cs.cmu.edu> <7860@nsc.nsc.com> <3614@pt.cs.cmu.edu> <10873@ulysses.homer.nj.att.com> <1073@actnyc.UUCP> <738@quintus.UUCP> <1988Nov25.180309.9323@utzoo.uucp>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 46

In article <1988Nov25.180309.9323@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <738@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>>	#use {filename}
>>... Easy to do, can't break old code, doesn't
>>require changes to the file being used.
>
>Well, leaving the existing construct alone (except perhaps in the presence
>of a compiler flag) is the right thing to do, but "doesn't require changes
>to the file being used" is a bug, not a feature.  In most cases, the fact
>that #including a file n times is the same as including it once is a
>property of the file being included, not the file doing the including.

Which is why "doesn't require changes to the file being used" is NOT
a design error.  If it is the case that including the file N times is
ok, then the file doesn't NEED _any_ changes.  If it is not the case
that including the file N times is ok, then a construct like this should
not be used.  What I had in mind is the situation where someone *else*
owns the header file in question, so that you _can't_ change it.  Ok,
you can get around that by interposing your own file which says
#pragma include_once; #include "the-real-file"
but you can just as easily do that by putting
	#ifndef	FOOBAZ_H
	#include "real_foobaz.h"
	#define	FOOBAZ_H 1
	#endif
in your "foobaz.h" file.  Actually, now that I come to think of it,
just how hard _is_ it to write a 4-line wrapper in order to make anmult
idempotent version of a header?

I'm afraid that it is not really the case that idempotence is "a property
of the file being included, not the file doing the including.", only if
the file being included contains no identifiers which could be #defined
by the caller.  Suppose we have
	extern int strlen(char*);
in a file strlen.h.  Now consider
	#define int double
	#define strlen atof
	#include "strlen.h"
	#undef int
	#undef strlen
	#include "strlen.h"
Not a terribly reasonable thing to do, but sufficient to show that the
idempotence of even such an innocent header as that IS dependent on the
includer, so that it *is* advisable for the includer to explicitly
promise not to break it.  "In most cases", true, this doesn't happen,
but that is a property of the includer!