brahms@mindspring.com (Stan Brown) writes:

>On the penultimate page of /D&E/, Stroustrup says that he proposed an
>include directive native to C++, to correct some of the worst problems
>with the preprocessor #include and unscoped #define.
>
>I'm wondering what the counter-arguments might have been, since this
>proposal did not find its way into the language.

The counter-arguments were essentially that it was proposed too late,
and that C++ already had too many features.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Stan Brown wrote:

> "(1) If a file is included twice, the second include is ignored. This
> solves a practical problem that is currently solved inefficiently and
> awkwardly by #defines and #ifdefs.
>
> "(2) Macros defined outside included text don't get expanded within the
> included text. This provides a mechanism for insulating information from
> interference by macros.
>
> "(3) Macros defined inside included text don't get expanded in text
> processed after the included text. This ensures that macros in included
> text don't impose order dependencies on the including compilation unit
> and generally protects against surprises caused by macros.

It should be quite easy to write a program which does
that (pseudo-code):

global already_included = emptyset

expand (file)
   cpp file > file.preproc
   for each line L in file.preproc
      if L is "include .*"
         remove L
         if L isn't in already_included
            already_included += L
            insert (expand (filename (L)))

All you need is to have separated cpp and CC. Anyone ?

--

Valentin Bonnard


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

bs@research.att.com (Bjarne Stroustrup) wrote in comp.std.c++:
>The main reason for not formally proposing an "include directive" was that
>I did not think that the details would be easy to get right and I didn't
>have the time to conduct proper experiments (beyond the ones that led to
>that page being written).

[much snipped]

Thanks for the answer.

One recurring theme in /D&E/ is how much experimentation and discussion
went into each decision about what went into C++. The mix changed with
the inauguration of the standards committee.

I've said it before, but I recommend everyone who has been with C++ for a
while to read Stroustrup's /The Design and Evolution of C++/. I think
it's a good way to get a sense of the "soul" of the language, up through
1994 anyway. You won't learn many language features, but you'll learn a
lot about why the language contains some things and not others, and get
an appreciation for the vision that has made it so successful. (Maybe a
revision is in the works, hopefully after /The Annotated C+ Standard/ ?)

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
http://www.mindspring.com/~brahms/

"It's my opinion, and it's very true."


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On the penultimate page of /D&E/, Stroustrup says that he proposed an
include directive native to C++, to correct some of the worst problems
with the preprocessor #include and unscoped #define.

I'm wondering what the counter-arguments might have been, since this
proposal did not find its way into the language. Here's the proposal, as
described on page 425 of D&E:

"I have suggested that an include directive might be added to C++ proper
as an alternative to Cpp's #include. A C++ include directive would differ
from Cpp's #include in three ways:

"(1) If a file is included twice, the second include is ignored. This
solves a practical problem that is currently solved inefficiently and
awkwardly by #defines and #ifdefs.

"(2) Macros defined outside included text don't get expanded within the
included text. This provides a mechanism for insulating information from
interference by macros.

"(3) Macros defined inside included text don't get expanded in text
processed after the included text. This ensures that macros in included
text don't impose order dependencies on the including compilation unit
and generally protects against surprises caused by macros.

"This mechanism would be a boon to systems that precompile header files
and, in general, for people who compose software out of independent
parts. Please note, however, that this is only an idea, not an accepted
language feature."

The benefits are so obvious that there must have been some compelling
reason why this idea was not accepted. (Obviously #include couldn't be
eliminated because there's too much existing code, but it might have been
deprecated.)

Does anybody know why this proposal was not accepted by the committee?

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
http://www.mindspring.com/~brahms/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Stan Brown wrote:

> I'm wondering what the counter-arguments might have been, since this
> proposal did not find its way into the language. Here's the proposal, as
> described on page 425 of D&E:
>
> "I have suggested that an include directive might be added to C++ proper
> as an alternative to Cpp's #include. A C++ include directive would differ
> from Cpp's #include in three ways:
>
> "(1) If a file is included twice, the second include is ignored. This
> solves a practical problem that is currently solved inefficiently and
> awkwardly by #defines and #ifdefs.
>
> "(2) Macros defined outside included text don't get expanded within the
> included text. This provides a mechanism for insulating information from
> interference by macros.
>
> "(3) Macros defined inside included text don't get expanded in text
> processed after the included text. This ensures that macros in included
> text don't impose order dependencies on the including compilation unit
> and generally protects against surprises caused by macros.

It's still insufficient:

foo:
int j = i;

bar:
int i;
include "foo"

It doesn't allow real precompiled headers. It doesn't allow us to
remove the ODR, which is the real goal.

> The benefits are so obvious that there must have been some compelling
> reason why this idea was not accepted.

Because it has never been proposed ? (I am just guessing, I don't
know if it has been proposed.)

> (Obviously #include couldn't be
> eliminated because there's too much existing code, but it might have been
> deprecated.)

No, since the C library depends on it (assert).

--

Valentin Bonnard


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]