Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!polya!shap
From: shap@polya.Stanford.EDU (Jonathan S. Shapiro)
Newsgroups: comp.lang.c++
Subject: Re: Managing C/C++ Libraries: Dependencies
Message-ID: <5044@polya.Stanford.EDU>
Date: 14 Nov 88 18:43:39 GMT
References: <8387@nlm-mcs.arpa> <3414@geaclib.UUCP>
Reply-To: shap@polya.Stanford.EDU (Jonathan S. Shapiro)
Organization: Stanford University
Lines: 34

In article <3414@geaclib.UUCP> geaclib!lethe!dave writes:
>> 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
>]
> 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.
>
>--dave c-b

That misses the point.  There is already a mechanism in place to do
this sort of thing (described above).  The danger of inserting
features like this is that they constrain future options for the
language.

The ANSI committee, as I recall, at one point debated having #include
work this way.  I don't recall the resolution, but it was a lousy
idea. Being able to reinclude files is useful. Your idea wouldn't
break that, but would introduce some unsual stuff that clearly isn't
necessary.

Further, #include_once puts the onus in the wrong place.  The decision
should be up to the included file, not the includer.  This frees the
include-file implementor to change the implementation transparently to
your code.

Jon