Yves Arrouye (arrouye@marin.fdn.fr) wrote:
> In article <4fukhs$fc3@hermes.acs.unt.edu> johnw@jove.acs.unt.edu
> (John R. Williams) writes:
>    Personally I'll continue to advocate "#once" to prevent multiple

> So instead of adding yet another preprocessor directive, why not use
> Objective C's #import which does exactly that? (I know this is also a
> reason for *not* using it in order to make clear that the header file
> is a C++ one, but I don't tjink it will be sooo confusing).

I don't follow. How does adding #import rather than #once prevent another
directive from being added to the language?

--
class JohnWilliams : public Student, public Programmer {
public:
  string operator&() const { return "johnw@jove.acs.unt.edu"; }
  string homepage () const { return "http://www.unt.edu/~johnw"; }
};
---
[ To submit articles: try just posting with your news-reader.
                      If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu.
]

>>>>> "JRW" == John R Williams <johnw@jove.acs.unt.edu> writes:

 JRW> Also something I have often wished for was something like #warning
 JRW> which would cause the compiler to emit a warning.

I'd like to see `#assert':

   #assert sizeof(int)==4

which would be like

   #if sizeof(int)!=4
   #error
   #endif

except that it would work.  That is, #assert would be a compiler directive,
not a preprocessor directive, and so there would be no restrictions on the
kinds of expressions.

Michael.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

John R. Williams (johnw@jove.acs.unt.edu) wrote:
| I think it would be even better to make "#pragma once" (a common C
| extension, AFAIK) into a standardized directive ("#once"?). This would
| probably save an average of 30 characters per header (the most annoying
| ones in the whole language(s), IMO).

At least one C++ compiler vendor (MetaWare) implements #c_include, which
has the same semantics as #include, except that it is ignored the second
and subsequent times that it is encountered for the same file.

| Also something I have often wished for was something like #warning which
| would cause the compiler to emit a warning.

Coincidentally, the same compiler vendor provides #print.  It's quite
useful, actually.

As I've said before, many features that people so often find desirable are
actually already implemented by compiler vendors.  Vote with your wallets.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

Charles F. McDevitt wrote:
> Marek MAKOWSKI wrote:
> > Would not it be sensible to add to the preprocessing a directive
> > that would stop processing the current file ? Something like
> > #ifdef XXXX
> > #exit
> > this would safe processing (sometimes very long) file in the common
> > situations:
> > #ifdef XXXX
> > // a (possibly) long header file hear
> > #endif  /* ifdef XXXX*/
> Wouldn't it be better to update the C++ standard so the
> default is that include files only get included once, and the
> compiler/preprocessor keeps track of which ones it's already
> seen.  Then we wouldn't have to mess with these ugly #ifdefs
> to make include files only be included once.

The problem with letting the compiler handle multiple inclusion is:

#define TYPES_ONLY
#include "header.h"

#define FUNCTIONS_ONLY
#include "header.h"

In this case, the header optionally defines functions, types, etc.  If the
compiler were to leave out the second include, the functions would not be
available.

The whole problem is that we are using ancient technology for source code.
Instead of plain-text files, we should be using smart databases that
automatically generate/include the headers that are needed.  But, that isn't
going to happen in the near future.  In the meantime, I think that an #exit
preprocessor directive would be a reasonable solution to speed up include
file processing.

One thing to be considered:  Since keywords and directives are file-context
insensitive, what happens for an #exit encountered in source (non-header).
I would think that it would simply abort processing for the remainder of
that file.

--
Bret Pehrson        BretP@strata3d.com
*Please respond to newsgroup unless specified otherwise
--
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

Fergus Henderson wrote:
> However, implementations can (and some do) optimize the processing of
> files using the standard guard technique so that they are only read
> when necessary.  This optimization actually improves performance more
> than your `#exit' would, because it avoids even opening the file the
> second and subsequent times.[snip]

Unfortunately, not all programmers, libraries, code generators, etc.
feel the need to define a token for their header file.  Also, it would
be nice if there were some pseudo-standard that defines the actual
token to be defined (instead of _foo_included, __FOO_H, FOO_H, ...).
It gets a little boring opening each header to see what the actual
token is.  As for our shop, we use __HEADERNAME_H__.

--
Bret Pehrson        BretP@strata3d.com
*Please respond to newsgroup unless specified otherwise
--
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

What about Bjarne's idea of "include" as a keyword that only has the effect
of a #include if the file has not been "include"d already.

I suppose the idea is that the compiler builds a table (like gcc does for
wrapped includes) - pretty simple really.

Ideas about why this won't work ???

Dom
--
_____________________________________________________________________________
  Dom De Vitto                                 devitto@ferndown.ate.slb.com
  Schlumberger Automatic Test Equipment                      fox@bcs.org.uk
  Board Systems                          Desk/voicemail: +44(0) 1202 850951
  Wimborne, Dorset,                      Site reception: +44(0) 1202 850850
  England, BH21 7PP                      Fax:            +44(0) 1202 850988
_____________________________________________________________________________
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

Jonathan de Boyne Pollard (JdeBP@jba.co.uk) wrote:
: Steve Clamage (clamage@Eng.sun.com) wrote:
: | In article som@silver.jba.co.uk, JdeBP@jba.co.uk (Jonathan de Boyne
: | Pollard) writes:
: | >As I've said before, many features that people so often find desirable
: | >are actually already implemented by compiler vendors.  Vote with your
: | >wallets.
: |
: | For example, if you port your code using #c_include to any compiler I use,
: | it won't compile.

: Which is exactly why people are posting here that some feature like
: #c_include, #exit, or #once is desirable in the language standard itself.

Except for the fact that reasonable compilers _can_ and _do_ figure
out if a given file is needs to be included or not _without_
any special syntax.  If your compiler is too stupid to figure it out
without a special clue, complain to your compiler vendor.

[earlier posters have explained at length how a decent compiler can
 detect that a file matches the #ifndef #define ... #endif pattern,
 and not even open it the second time they see a #include]

If your compiler uses something like #once or #c_include, instead of
something like #pragma which other compilers can ignore, you have yet
another reason to complain.

---------------------------------------------------------------------------
Tim Hollebeek      | Disclaimer :=> Everything above is a true statement,
<space for rent>   |                for sufficiently false values of true.
Princeton Univ.    | email: tim@wfn-shop.princeton.edu
-------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

Would not it be sensible to add to the preprocessing a directive
that would stop processing the current file ? Something like

#ifdef XXXX
#exit

this would safe processing (sometimes very long) file in the common
situations:

#ifdef XXXX
// a (possibly) long header file hear
#endif  /* ifdef XXXX*/

Marek Makowski

--
                  Marek Makowski  | Email: marek@iiasa.ac.at
         International Institute  | Phone: (+43-2236) 807.561
    for Applied Systems Analysis  | Fax:   (+43-2236) 71.313
       A-2361 Laxenburg, Austria  | Web: http://www.iiasa.ac.at
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Marek MAKOWSKI wrote:
>
> Would not it be sensible to add to the preprocessing a directive
> that would stop processing the current file ? Something like
>
> #ifdef XXXX
> #exit
>
> this would safe processing (sometimes very long) file in the common
> situations:
>
> #ifdef XXXX
> // a (possibly) long header file hear
> #endif  /* ifdef XXXX*/
>

Wouldn't it be better to update the C++ standard so the
default is that include files only get included once, and the
compiler/preprocessor keeps track of which ones it's already
seen.  Then we wouldn't have to mess with these ugly #ifdefs
to make include files only be included once.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

marek@iiasa.ac.at (Marek  MAKOWSKI) writes:

>Would not it be sensible to add to the preprocessing a directive
>that would stop processing the current file ?

I don't think it would be very useful.

>Something like
>
>#ifdef XXXX
>#exit
>
>this would safe processing (sometimes very long) file in the common
>situations:
>
>#ifdef XXXX
>// a (possibly) long header file hear
>#endif  /* ifdef XXXX*/

There is one situation in which this is very common: headers that
are guarded against multiple inclusion:

 #ifndef FOO_H
 #define FOO_H
 ... code for foo.h ...
 #endif

With your proposal, this could be rewritten as

 #ifdef FOO_H
 #exit
 #endif
 #define FOO_H
 ... code for foo.h ...

However, implementations can (and some do) optimize the processing of
files using the standard guard technique so that they are only read
when necessary.  This optimization actually improves performance more
than your `#exit' would, because it avoids even opening the file the
second and subsequent times.

`#exit' is not necessary for performance; adding `#exit' would not improve
performance for already existing code; and use of `#exit' would require
four preprocessor directives to guard include files rather than the three
required by the standard guard idiom.  So I think adding `#exit' would be
a bad idea.

--
Fergus Henderson              WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au               PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In message <DMBrxn.GAB@falcon.daytonoh.attgis.com> - Dick Menninger <Dick.Menni
nger@daytonoh.attgis.com> writes:
:>
[...]
:>>name techniques are needed to do other semantics.  But an
:>include file can be a form of template for source construction
:>that could be included many times on purpose.  That is what
:>you are proposing to eliminate.
[...]

I don't see it eliminating old operation just adding a feature which is used
frequently and is time consuming.
The author of an included file knows if including beyond a point produces
anything that is redundant and can tell the compiler to stop looking at it.

I would even go farther and propose something like:

#invariant

which would tell the compiler to stop scanning this file if it already had
scanned it before.  This is not as efficient as not including it at all, but
then the programmer doesn't need to know if the results are different each
time.

Ken Walter

* All the above is hearsay and the opinion of nobody in particular
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

"Charles F. McDevitt" <Chuck.McDevitt@elsegundoca.attgis.com> wrote:

>Wouldn't it be better to update the C++ standard so the
>default is that include files only get included once, and the
>compiler/preprocessor keeps track of which ones it's already
>seen.  Then we wouldn't have to mess with these ugly #ifdefs
>to make include files only be included once.

This would require adding some special directive to deal with those
headers that may need to be included more than once.  E.g. assert.h may
be included any number of times, and depending on the current defintion
of NDEBUG, the definition of assert will change with each new inclusion.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

Marek  MAKOWSKI (marek@iiasa.ac.at) wrote:
> Would not it be sensible to add to the preprocessing a directive
> that would stop processing the current file ? Something like

> #ifdef XXXX
> #exit

> this would safe processing (sometimes very long) file in the common
> situations:

> #ifdef XXXX
> // a (possibly) long header file hear
> #endif  /* ifdef XXXX*/

I think it would be even better to make "#pragma once" (a common C
extension, AFAIK) into a standardized directive ("#once"?). This would
probably save an average of 30 characters per header (the most annoying
ones in the whole language(s), IMO).

OTOH I can see how #exit would have good uses.

Also something I have often wished for was something like #warning which
would cause the compiler to emit a warning.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

In article <4fukhs$fc3@hermes.acs.unt.edu> johnw@jove.acs.unt.edu
(John R. Williams) writes:

   devitto@ferndown.ate.slb.com wrote:
   > What about Bjarne's idea of "include" as a keyword that only has the
   > effect of a #include if the file has not been "include"d already.

   > I suppose the idea is that the compiler builds a table (like gcc does for
   > wrapped includes) - pretty simple really.

   > Ideas about why this won't work ???

   Personally I'll continue to advocate "#once" to prevent multiple
   inclusion of a header for these reasons:

So instead of adding yet another preprocessor directive, why not use
Objective C's #import which does exactly that? (I know this is also a
reason for *not* using it in order to make clear that the header file
is a C++ one, but I don't tjink it will be sooo confusing).

YA.
--
Yves Arrouye       |  arrouye@marin.fdn.fr | http://www-scope.imag.fr/~arrouye
7, av. Leon Bollee +-----------------------+---------+------------------------
75013 Paris        |  Home voice: +33 1 53 61 09 55  |  Fax: +33 1 53 61 09 55
France             |  Please use these only between 8:00 AM and 11:00 PM, MET!
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]