🚀 go-pugleaf

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 article <1996Feb1.092058.4745@iiasa.ac.at> 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 ? 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*/

Why bother?  The usual procedure is for the compiler to recognize the
pattern the first time it reads the file, and not even open it in
further include declarations.

(I know that g++ does this, but I seem to recall from some earlier
discussion someone at Sun claiming that they had done measurements, and
it wasn't worth the bother.  Given that it sometimes takes close to a
second to open a file on one customer's network, I'm rather sceptical of
these results.)

-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
              -- A la recherche d'une activité dans une region francophone

[ 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://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]

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

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

Not necessarily a good idea. What about if another header file adds a define
and running thru the header file a second time includes a different contents
than the first time around.
This is a very common practice in imake config files for example, which use
the preprocessor from C to process all the include files. And it would have
to be the preprocessor to take care of the tracking.
I can't imagine what a nightmare that would be to get some of the old
stuff to compile ;-) - not that I think that this is a very good coding
practice.

							Jan


[ 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://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]

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

>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 that idea is that it is not backwards compatible,
and would break a very large amount of existing code.

--
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://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. ]

>>>>> "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. ]

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:

  Although it adds no new capability to the language, it would be trivial 
  to implement and to specify in a standard. The benefit it that it
  prevents programmers from having to do a little of the kind of mindless
  robotic work that computers do so much better than humans.

  I don't like Bjarne's idea because I would think that the writer of
  any given header knows more about how many times it should be included
  than the user. If it *does* need to be multi-included, it is reasonable
  to expect to the programmer would forget to use the traditional include
  mechanism alarmingly often. C++ already has enough things like this that
  silently cause strange errors when the programmer forgets something
  (like everyone's favorite, the switch statement). Conversely, many would 
  countinue to use the old mechanism, which would not work too well, while 
  #once is 100% backwards compatible.

--
#define REAL_NAME "John Williams"
#define E_MAIL    "johnw@jove.acs.unt.edu"
#define HOMEPAGE  "http://www.unt.edu/~johnw"
---
[ 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. ]

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'm okay with it as long as we leave something to mean the old
include-no-matter-what behavior.

A common trick for making an array that includes pointers to functions is
something like:

file1.h --------

func(foo);
func(bar);



file2.cc ------

#define func(x)		int x(char*);
#include <file1.h>
#undef func
#define func(x)		{ ##x, x },

struct funcHandle {
    const char* const          name;
    const int (* const)(char*) function;
} funcArray[] = {
#include <file1.h>
};

--------------

It may be overly clever, but I've seen this one in almost every C/C++ shop
I've worked in.

--
Micha Berger 201 916-0287        Help free Ron Arad, held by Syria 3255 days!
AishDas@haven.ios.com                     (16-Oct-86 -  5-Oct-95)
<a href=news:alt.religion.aishdas>Orthodox Judaism: Torah, Avodah, Chessed</a>
<a href=http://haven.ios.com/~aishdas>AishDas Society's Home Page</a>

[ 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://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]

In article <9602141406.AA16760@sparc5.ferndown.ate.slb.com>
devitto@ferndown.ate.slb.com writes:

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

Bjarne's idea of include as a keyword went farther than that.  If it did
include the file, it included it in its own environment.  User macros,
for example, couldn't mess it up.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ 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. ]

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.
]