Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!olivea!apple!agate!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: A question on C programming style
Message-ID: <12060@dog.ee.lbl.gov>
Date: 13 Apr 91 11:59:13 GMT
References: <1991Apr12.103621.8907@umiami.ir.miami.edu> <1991Apr13.013911.18151@athena.mit.edu>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 41
X-Local-Date: Sat, 13 Apr 91 04:59:14 PDT

In article <1991Apr13.013911.18151@athena.mit.edu> scs@adam.mit.edu writes:
>Whether nested #included files are good style is, historically,
>(like so many of these style questions :-( ) a bit of a religious
>question.  (ANSI's new guarantees may have shifted the balance
>somewhat.)

Indeed.  One thing, for which I argued (and still will argue---it
seems `right' to me) which is not standard, would tip the balance
all the way:  I believe that `#include' should (always) have been
defined as `read this if you have not already'.

Such a definition would mean that

	#define TABLEENTRY(a, b, c) a
	int atable[] = {
	#include "table"
	};
	#undef TABLEENTRY
	#define TABLEENTRY(a, b, c) c
	int ctable[] = {
	#include "table"
	};
	#undef TABLEENTRY

would fail.  It also leaves open the question of spelling: is

	#include "./table"

`the same' as

	#include "table"

?  All of these would have to have been answered in trial
implementations, which (alas) did not exist when the standard was in
progress, and now no doubt never will.  (My answers would be
`#read'---unconditionally read in a file---and `files are considered
identical only if spelled identically' or `identity of files is
implementation-defined'.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov