Xref: utzoo comp.lang.c++:1992 comp.lang.c:14112
Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!bloom-beacon!apple!amdahl!rtech!llama!daveb
From: daveb@llama.rtech.UUCP (Dave Brower)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: Managing C/C++ Libraries: Dependencies
Message-ID: <2539@rtech.rtech.com>
Date: 14 Nov 88 22:00:56 GMT
References: <8387@nlm-mcs.arpa> <3414@geaclib.UUCP>
Sender: news@rtech.rtech.com
Reply-To: daveb@llama.UUCP (Dave Brower)
Organization: Relational Technology, Inc. Alameda, CA
Lines: 21

In article <3414@geaclib.UUCP> geaclib!lethe!dave writes:
>>>#include_once "classname.h"

>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 ? 
>
> 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?

Well, it will certainly break this year's Obfuscated C contest winner,
which calulated prime numbers in the preprocessor with use of multiple
inclusion and defined/undefed state variables.  Some might say it is
not a "proper" program, but it falls within the letter of the existing
and proposed laws.

-dB
"You have to run twice as fast to get anywhere" - Ben Johnson.
{amdahl, cpsc6a, mtxinu, sun, hoptoad}!rtech!daveb daveb@rtech.com