Xref: utzoo comp.lang.c++:1952 comp.lang.c:14028
Path: utzoo!yunexus!geac!geaclib!lethe!dave
From: dave@lethe.UUCP (David Collier-Brown)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Managing C/C++ Libraries: Dependencies
Message-ID: <3414@geaclib.UUCP>
Date: 13 Nov 88 03:01:10 GMT
Article-I.D.: geaclib.3414
References: <8387@nlm-mcs.arpa>
Sender: daveb@geaclib.UUCP
Reply-To: geaclib!lethe!dave
Followup-To: comp.lang.c++
Organization: Interleaf Canada Inc. (News courtesy of Geac)
Lines: 27

> In article <124300001@inmet> stt@inmet writes:
>>A simple language extension would be:
>>
>>#include_once "classname.h"
[definition of include_once as equivalent to
 #ifdef classname_h
 #  include "classname.h"
 #  define classname_h
 #endif
]

From article <8387@nlm-mcs.arpa>, by mjr@vax2.nlm.nih.gov.nlm.nih.gov (Marcus J. Ranum):
> 	I wonder how much code would break is such an extension were added,
> and the #include_once were made the DEFAULT rather than the exception ? 

  I suspect very little: I used such a construct in a preprocessor
for multiple languages without further thought, and my C programs
tend to work correctly (they may, in fact, therefor be incorrect
:-). I'm crossposting the question to comp.lang.c for further
discussion.

 Ok, people! Would this change, made silently, injure correct
programs?  It is admitted that it may allow incorrect programs to
compile, but that isn't waht I'm concerned about.
  Specifically, what about include trees which cannot be tsorted?

--dave c-b