m@rtij.nl.removefromhere.invalid (Martijn Lievaart) writes:

> On Mon, 09 Jun 2003 23:05:51 +0000, Andrey Tarasevich wrote:
>
> [ #once ]
>>
>> Yeah, but it looks like the main point of the method Brian is using is that
>> the guarding '#ifndef'/'#endif' is placed _outside_ the header file. In this
>> case the preprocessor doesn't even have to search for already included
>> files, open them or try parsing them. The '#once' solution doesn't help in
>> this case, since '#once' directive is supposed to be specified _inside_
>> header files. From this respect '#once' is not much different from the
>> standard  "internal '#ifndef'/'#define'/'#endif' approach". But it looks
>> like Brian is not satisfied with the latter. Under this circumstances, I
>> don't think he will be satisfied with any other "internal" solution.
>
> I don't think so. The compiler can 'cache' the #once and skip the header
> when the #include directive is seen again.
>
> Hmmmm, as a QoI issue, a compiler /could/ recognize header guards and
> treat the as #once.... Hmmmm.
>
> M4

And in fact some compilers do:

gcc.gnu.org/onlinedocs/gcc-3.3/cpp/Once-Only-Headers.html#Once-Only%20Headers

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis> Being able to write:

Francis> #once

Francis> at the start of a header file would solve the problem because
Francis> compilers would then read the file the first time, mark it as
Francis> read in its tables and not try to read it again.

There are already compilers that detect header files of the form

        #ifndef <symbol>

                anything

        #endif

(and similarly for #ifdef), and decline to process the file a second
time if <symbol> is set (or unset) when the file is included a second
time.  For such compilers, no special directives are needed.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

>> Doesn't seem likely.  There is no requirement that the standard
>> headers even be implemented as files in the first place.

Makes perfect sense.

Whilst this may be true, all of the C++ implementations that I use (5 total)
all implement most, if not all, of the of the standard library as files.
(please note that I only checked iostream and amongst these 5, all
implemented iostream as a file).  Given this, couldn't we at least make a
recommendation in the standard that "if you do implement the standard
library include "files" as actual files then the include guards in this file
should take the form of blah, blah, blah..."

If this step was taken and in thoses cases where the the standard library
was implemented as files, this standardization combined with the external
header guards that I described in my original post would/could save
significant amounts of compile time without any introduction of other
"sophisticated" features that may or may not be found in "modern" C++
compilers.

Brian




"Andrew Koenig" <ark@research.att.com> wrote in message
news:yu997k7swza8.fsf@europa.research.att.com...
> Brian> I have the following recommendation for an addition to the C++
> Brian> standard: I'd like to see the text used for the header guards
> Brian> in the standard library header files, well, standardized.
>
> Doesn't seem likely.  There is no requirement that the standard
> headers even be implemented as files in the first place.
>
> --
> Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark
>
> ---
> [ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]
>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Brian> Whilst this may be true, all of the C++ implementations that I
Brian> use (5 total) all implement most, if not all, of the of the
Brian> standard library as files.  (please note that I only checked
Brian> iostream and amongst these 5, all implemented iostream as a
Brian> file).  Given this, couldn't we at least make a recommendation
Brian> in the standard that "if you do implement the standard library
Brian> include "files" as actual files then the include guards in this
Brian> file should take the form of blah, blah, blah..."

Sure -- but why not make the following recommendation instead:

        Implementations are urged to arrange that a program
        that includes a system header two or more times processes
        the system header only once, except for cases such as
        assert.h in which doing so would change the semantics.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

bplummer@hotmail.com ("Brian Plummer") wrote in message news:<iqQFa.10646$Fu.3596564@twister.nyc.rr.com>...
> >> Doesn't seem likely.  There is no requirement that the standard
> >> headers even be implemented as files in the first place.
>
> Makes perfect sense.
>
> Whilst this may be true, all of the C++ implementations that I use (5 total)
> all implement most, if not all, of the of the standard library as files.
> (please note that I only checked iostream and amongst these 5, all
> implemented iostream as a file).  Given this, couldn't we at least make a
> recommendation in the standard that "if you do implement the standard
> library include "files" as actual files then the include guards in this file
> should take the form of blah, blah, blah..."

In fact, it could be phrased a lot easier like:

Header <X> shall define symbol __HDR_X where X is one of the following
[Table]

Even where system headers aren't files preprocessor symbols can
be defined. This is required for e.g. <cstdlib>

If these are used as include guards on such no-header-file systems, the
effect is the same as on normal systems - no effect except for <cassert>
although compile times can be different.

Still, is it worth the trouble?

Regards,
--
Michiel Salters

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

I have the following recommendation for an addition to the C++ standard:

I'd like to see the text used for the header guards in the standard library
header files, well, standardized.

Why? You ask...

Well, almost all of the code I write is portable to a large number of
Hardware/OS/Compiler combinations and I (try to) employ a technique to
reduce compile times discussed by Lakos on pages 82-88 of "Large Scale C++
Software Design" which advocates protecting every #include file directive
with a redundant check for previous inclusion of said header in the
translation unit.  An example could be:

#ifndef __IOSTREAM__
#include <iostream>
#endif

This is what I would use if I was using the cygwin hosted gcc 3.1 that is
installed on my Windows machine.  If I want to accomplish this same thing
with MSVC (Microsoft Visual Studio .NET 2003) I would have to use the
following:

#ifndef _IOSTREAM_
#include <iostream>
#endif

The problem here is that the MSVC header guard for iostream only uses one
(1) underscore instead of 2 as in the gcc header guard for iostream.  So, if
I compile my code using the gcc header guard check as displayed in the first
example with MSVC, my attempt at eliminating redundant inclusion fails,
silently, because the header guards are different.

I'm assuming that you are familiar with this technique.  If not, you should
take a quick look at the pages I site from Lakos.  Its a very
straight-forward technique and when carefully employed it can dramatically
reduce compile times on large projects, especially if the standard library
headers are widely referred to in the project's header files which is
becoming ever more prevalent with the exploding use of template classes and
functions.

If the header guard text was standardized then I can employ this technique
without having to worry about how Library Vendor X has assembled the header
guard text.

Thats all there is to it.

Thanks,
Brian Plummer

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Brian Plummer"" <bplummer@nyc.rr.com> wrote in message
news:ohQDa.44053$4_1.12732776@twister.nyc.rr.com...
> I have the following recommendation for an addition to the C++
standard:
>
> I'd like to see the text used for the header guards in the standard
library
> header files, well, standardized.
>
> Why? You ask...
>
> Well, almost all of the code I write is portable to a large number of
> Hardware/OS/Compiler combinations and I (try to) employ a technique to
> reduce compile times discussed by Lakos on pages 82-88 of "Large Scale
C++
> Software Design" which advocates protecting every #include file
directive
> with a redundant check for previous inclusion of said header in the
> translation unit.  An example could be:
>
> #ifndef __IOSTREAM__
> #include <iostream>
> #endif

This only works if you know and can rely on the include guards, as you
say, regardless of what library/include file is used. This creates a
dependency on the implementation of the header (the include guards), and
the code in the including file can be quite messy, tripling the number
of lines dealing with includes.

A better way might be the "#once" directive, which has been discussed
recently, which ensures that the header using it is only included once.
This means you have no dependency on the included file, and files
including it don't need to be changed.

The thread is here
(http://www.google.com/groups?selm=Xns9343937778AB1conley141osuedu%4065.
24.2.11).


Regards,

Terje

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

>> A better way might be the "#once" directive, which has been discussed
>> recently, which ensures that the header using it is only included once.
>> This means you have no dependency on the included file, and files
>> including it don't need to be changed.
>>
>> The thread is here
>> (http://www.google.com/groups?selm=Xns9343937778AB1conley141osuedu%4065.
>> 24.2.11).


That is definitely an even better idea! Google could not locate the thread
that you referenced in your reply. In general I'd like to see that this
topic is at least on the discussion agenda for the Library Standards
Committee. I don't know how to do this, do you?


"Terje Sletteb   " <tslettebo@chello.no.nospam> wrote in message
news:_ULEa.10852$KF1.271850@amstwist00...
> ""Brian Plummer"" <bplummer@nyc.rr.com> wrote in message
> news:ohQDa.44053$4_1.12732776@twister.nyc.rr.com...
> > I have the following recommendation for an addition to the C++
> standard:
> >
> > I'd like to see the text used for the header guards in the standard
> library
> > header files, well, standardized.
> >
> > Why? You ask...
> >
> > Well, almost all of the code I write is portable to a large number of
> > Hardware/OS/Compiler combinations and I (try to) employ a technique to
> > reduce compile times discussed by Lakos on pages 82-88 of "Large Scale
> C++
> > Software Design" which advocates protecting every #include file
> directive
> > with a redundant check for previous inclusion of said header in the
> > translation unit.  An example could be:
> >
> > #ifndef __IOSTREAM__
> > #include <iostream>
> > #endif
>
> This only works if you know and can rely on the include guards, as you
> say, regardless of what library/include file is used. This creates a
> dependency on the implementation of the header (the include guards), and
> the code in the including file can be quite messy, tripling the number
> of lines dealing with includes.
>
> A better way might be the "#once" directive, which has been discussed
> recently, which ensures that the header using it is only included once.
> This means you have no dependency on the included file, and files
> including it don't need to be changed.
>
> The thread is here
> (http://www.google.com/groups?selm=Xns9343937778AB1conley141osuedu%4065.
> 24.2.11).
>
>
> Regards,
>
> Terje
>
> ---
> [ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]
>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Brian Plummer wrote:
> ...
> Well, almost all of the code I write is portable to a large number of
> Hardware/OS/Compiler combinations and I (try to) employ a technique to
> reduce compile times discussed by Lakos on pages 82-88 of "Large Scale C++
> Software Design" which advocates protecting every #include file directive
> with a redundant check for previous inclusion of said header in the
> translation unit.  An example could be:
>
> #ifndef __IOSTREAM__
> #include <iostream>
> #endif
>
> This is what I would use if I was using the cygwin hosted gcc 3.1 that is
> installed on my Windows machine.  If I want to accomplish this same thing
> with MSVC (Microsoft Visual Studio .NET 2003) I would have to use the
> following:
>
> #ifndef _IOSTREAM_
> #include <iostream>
> #endif
>
> The problem here is that the MSVC header guard for iostream only uses one
> (1) underscore instead of 2 as in the gcc header guard for iostream.  So, if
> I compile my code using the gcc header guard check as displayed in the first
> example with MSVC, my attempt at eliminating redundant inclusion fails,
> silently, because the header guards are different.
>
> I'm assuming that you are familiar with this technique.  If not, you should
> take a quick look at the pages I site from Lakos.  Its a very
> straight-forward technique and when carefully employed it can dramatically
> reduce compile times on large projects, especially if the standard library
> headers are widely referred to in the project's header files which is
> becoming ever more prevalent with the exploding use of template classes and
> functions.
>
> If the header guard text was standardized then I can employ this technique
> without having to worry about how Library Vendor X has assembled the header
> guard text.
> ...

Well, since you are already doing as much as putting this '#ifndef'/'#endif'
guard _outside_ the header file (i.e. add it to every '#include' that refers
to this file), it really won't make things much harder if you add an
additional '#define' into the mix. Just make up your own guard names for
every header file and use them like this:

#ifndef MY_IOSTREAM_INCLUDED_
#define MY_IOSTREAM_INCLUDED_
#include <iostream>
#endif // MY_IOSTREAM_INCLUDED_

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Terje Sletteb=F8 wrote:
> ""Brian Plummer"" <bplummer@nyc.rr.com> wrote in message
> news:ohQDa.44053$4_1.12732776@twister.nyc.rr.com...
>> ...
>> Well, almost all of the code I write is portable to a large number of
>> Hardware/OS/Compiler combinations and I (try to) employ a technique to
>> reduce compile times discussed by Lakos on pages 82-88 of "Large Scale
> C++
>> Software Design" which advocates protecting every #include file
> directive
>> with a redundant check for previous inclusion of said header in the
>> translation unit.  An example could be:
>>
>> #ifndef __IOSTREAM__
>> #include <iostream>
>> #endif
> ...
> A better way might be the "#once" directive, which has been discussed
> recently, which ensures that the header using it is only included once.
> This means you have no dependency on the included file, and files
> including it don't need to be changed.
>=20
> The thread is here
> (http://www.google.com/groups?selm=3DXns9343937778AB1conley141osuedu%40=
65.
> 24.2.11).
> ...

Yeah, but it looks like the main point of the method Brian is using is th=
at
the guarding '#ifndef'/'#endif' is placed _outside_ the header file. In t=
his
case the preprocessor doesn't even have to search for already included
files, open them or try parsing them. The '#once' solution doesn't help i=
n
this case, since '#once' directive is supposed to be specified _inside_
header files. From this respect '#once' is not much different from the
standard  "internal '#ifndef'/'#define'/'#endif' approach". But it looks
like Brian is not satisfied with the latter. Under this circumstances, I
don't think he will be satisfied with any other "internal" solution.

--=20
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 09 Jun 2003 23:05:51 +0000, Andrey Tarasevich wrote:

[ #once ]
>
> Yeah, but it looks like the main point of the method Brian is using is that
> the guarding '#ifndef'/'#endif' is placed _outside_ the header file. In this
> case the preprocessor doesn't even have to search for already included
> files, open them or try parsing them. The '#once' solution doesn't help in
> this case, since '#once' directive is supposed to be specified _inside_
> header files. From this respect '#once' is not much different from the
> standard  "internal '#ifndef'/'#define'/'#endif' approach". But it looks
> like Brian is not satisfied with the latter. Under this circumstances, I
> don't think he will be satisfied with any other "internal" solution.

I don't think so. The compiler can 'cache' the #once and skip the header
when the #include directive is seen again.

Hmmmm, as a QoI issue, a compiler /could/ recognize header guards and
treat the as #once.... Hmmmm.

M4

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3EE50908.9060202@hotmail.com>, Andrey Tarasevich
<andreytarasevich@hotmail.com> writes
>Yeah, but it looks like the main point of the method Brian is using is that
>the guarding '#ifndef'/'#endif' is placed _outside_ the header file. In this
>case the preprocessor doesn't even have to search for already included
>files, open them or try parsing them. The '#once' solution doesn't help in
>this case, since '#once' directive is supposed to be specified _inside_
>header files. From this respect '#once' is not much different from the
>standard  "internal '#ifndef'/'#define'/'#endif' approach". But it looks
>like Brian is not satisfied with the latter. Under this circumstances, I
>don't think he will be satisfied with any other "internal" solution.

But I do not understand the problem. Only the designer of a header file
can know if it should or should not be multiply included into a TU.

Being able to write:

#once

at the start of a header file would solve the problem because compilers
would then read the file the first time, mark it as read in its tables
and not try to read it again.

Another solution would be to make header files default to single
inclusion per TU and provide a

#multiple

directive that over-ruled the default and required the compiler to
re-read the file each time it is included (sort of the pre-processor
equivalent of volatile).

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <VM6Fa.7759$Fu.2821557@twister.nyc.rr.com>, "Brian Plummer" wrote:
>>> A better way might be the "#once" directive, which has been discussed
>>> recently, which ensures that the header using it is only included once.
>>> This means you have no dependency on the included file, and files
>>> including it don't need to be changed.
>>>
>>> The thread is here
>>> (http://www.google.com/groups?selm=Xns9343937778AB1conley141osuedu%4065.
>>> 24.2.11).
>
>
> That is definitely an even better idea! Google could not locate the thread
> that you referenced in your reply.

You need to paste those two lines together.  Some news or mail software
has word-wrapped that line wrongly.

> In general I'd like to see that this topic is at least on the discussion
> agenda for the Library Standards Committee. I don't know how to do this,
> do you?

This was discussed to death only a few months ago in the thread referenced
above.  It turns out to be impractical to implement #once on many systems
as file identities cannot reliably be compared.   #ifndef guards can do the
job and where file identities can be compared some compilers/preprocessors
are smart enough to recognise guarded headers and avoid reading them again.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Brian> I have the following recommendation for an addition to the C++
Brian> standard: I'd like to see the text used for the header guards
Brian> in the standard library header files, well, standardized.

Doesn't seem likely.  There is no requirement that the standard
headers even be implemented as files in the first place.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

francis@robinton.demon.co.uk (Francis Glassborow) wrote in message
news:<k+yc72ENhb5+EweX@robinton.demon.co.uk>...
> In article <3EE50908.9060202@hotmail.com>, Andrey Tarasevich
> <andreytarasevich@hotmail.com> writes
> >Yeah, but it looks like the main point of the method Brian is using
> >is that the guarding '#ifndef'/'#endif' is placed _outside_ the
> >header file. In this case the preprocessor doesn't even have to
> >search for already included files, open them or try parsing them. The
> >'#once' solution doesn't help in this case, since '#once' directive
> >is supposed to be specified _inside_ header files. From this respect
> >'#once' is not much different from the standard "internal
> >'#ifndef'/'#define'/'#endif' approach". But it looks like Brian is
> >not satisfied with the latter. Under this circumstances, I don't
> >think he will be satisfied with any other "internal" solution.

> But I do not understand the problem. Only the designer of a header
> file can know if it should or should not be multiply included into a
> TU.

> Being able to write:

> #once

> at the start of a header file would solve the problem because
> compilers would then read the file the first time, mark it as read in
> its tables and not try to read it again.

> Another solution would be to make header files default to single
> inclusion per TU and provide a

> #multiple

> directive that over-ruled the default and required the compiler to
> re-read the file each time it is included (sort of the pre-processor
> equivalent of volatile).

This would be nice if we were creating the language from scratch, but we
have existing code to deal with.  I doubt if any existing headers which
expect to be included multiple times use #multiple.

And of course, without the historical baggage, I daresay that we could
come up with something better than #include entirely:-).

Finally, as has been pointed out, a compiler doesn't need #once for
this.  Good compilers already note when an included file is protected by
include guards, memorize the conditional, and when they see the same
file about to be included, verify the conditional, and only open the
file if it is false (and the contents would be read).

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T   l. : +33 (0)1 30 23 45 16

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Andrey Tarasevich" <andreytarasevich@hotmail.com> wrote in message
news:3EE50908.9060202@hotmail.com...
>Terje Sletteb=F8 wrote:
>> ""Brian Plummer"" <bplummer@nyc.rr.com> wrote in message
>> news:ohQDa.44053$4_1.12732776@twister.nyc.rr.com...
>>
>> A better way might be the "#once" directive, which has been discussed
>> recently, which ensures that the header using it is only included
once.
>> This means you have no dependency on the included file, and files
>> including it don't need to be changed.
>>
>> The thread is here
>>
(http://www.google.com/groups?selm=3DXns9343937778AB1conley141osuedu%4065.
>> 24.2.11).

>Yeah, but it looks like the main point of the method Brian is using is
that
>the guarding '#ifndef'/'#endif' is placed _outside_ the header file. In
this
>case the preprocessor doesn't even have to search for already included
>files, open them or try parsing them. The '#once' solution doesn't help
in
>this case, since '#once' directive is supposed to be specified _inside_
>header files.

The way I understand the #once proposal is that the implementation would
remember which files contain it, and which have already been included
during compilation, so that if they are requested again, in an include
directive, they are not even opened, as you say. This would accomplish
what he asked for, without having to have external guards.

I agree with you that if #once only replaced #ifdef/#define/#endif,
there wouldn't be much point with it.

>From this respect '#once' is not much different from the
>standard  "internal '#ifndef'/'#define'/'#endif' approach". But it
looks
>like Brian is not satisfied with the latter. Under this circumstances,
I
>don't think he will be satisfied with any other "internal" solution.

In this case, the "internal" solution has the same effect as his
"external" one.


Regards,

Terje

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Brian Plummer"" <bplummer@nyc.rr.com> wrote in message
news:VM6Fa.7759$Fu.2821557@twister.nyc.rr.com...
> >> A better way might be the "#once" directive, which has been
discussed
> >> recently, which ensures that the header using it is only included
once.
> >> This means you have no dependency on the included file, and files
> >> including it don't need to be changed.
> >>
> >> The thread is here
> >>
(http://www.google.com/groups?selm=Xns9343937778AB1conley141osuedu%4065.
> >> 24.2.11).
>
> That is definitely an even better idea! Google could not locate the
thread
> that you referenced in your reply. In general I'd like to see that
this
> topic is at least on the discussion agenda for the Library Standards
> Committee. I don't know how to do this, do you?


The given link should work, but as it's wrapped over two lines, you need
to paste it together before use (everything between the parentheses,
excluding the ">" signs). Also, as #once (or something like it) is not
in the current language, it wouldn't just need a library change, but
also a core change.

There are committee members reading this list, so just bringing it up
like this, brings it to their attention.


Regards,

Terje

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi,

The problem with this proposal is also that Standard does not even
guarantee that headers are physical files. The #include <...> directive
may just "swich on" the appropriate definitions, without reading any file.

It is also worth noting that modern compilers use the idiom described by
Lakos by themselves, I mean - you do not need to guard the #include
<...> directive with additional (external) #ifdefs. If the header
contains the internal guards (which do not need to be standardized), the
preprocessor regognizes them (everything in the header is inside the
internal guards) and if there is later #include with the same header
name, the file is simply not read, because the preprocessor already
knows there are internal guards that would make the inclusion futile.
With this in mind, there is probably no need at all to standardize
internal guards - just make this a Quality of Implementation issue for
compiler vendors. If some compiler does not have this feature, you will
just have to wait for the needless file scans (this may be a problem in
network environments, I know). But we gain implementation freedom at the
same time without putting too much stuff into the already thick Standard.

--
Maciej Sobczak
http://www.maciejsobczak.com/

Distributed programming lib for C, C++, Python & Tcl:
http://www.maciejsobczak.com/prog/yami/

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

bplummer@nyc.rr.com ("Brian Plummer") writes:

>I (try to) employ a technique to
>reduce compile times discussed by Lakos on pages 82-88 of "Large Scale C++
>Software Design" which advocates protecting every #include file directive
>with a redundant check for previous inclusion of said header in the
>translation unit.

This technique is a bad way to solve the problem.  It puts a significant
burden on C/C++ programmers, forever.

A much better way of solving the problem is for C/C++ implementors to
implement the "header guard optimization", i.e. to avoid opening header
files twice if they contains the usual kind of header file guard, and
the macro which is used as the guard has not been #undef'd since the
file was last included.  Good C/C++ implementations were already doing
this optimization years ago.  If your favourite C/C++ implementation
doesn't do this already, then lobby the vendor to do so, or switch to GCC!

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> In article <3EE50908.9060202@hotmail.com>, Andrey Tarasevich
> <andreytarasevich@hotmail.com> writes
>>Yeah, but it looks like the main point of the method Brian is using is that
>>the guarding '#ifndef'/'#endif' is placed _outside_ the header file. In this
>>case the preprocessor doesn't even have to search for already included
>>files, open them or try parsing them. The '#once' solution doesn't help in
>>this case, since '#once' directive is supposed to be specified _inside_
>>header files. From this respect '#once' is not much different from the
>>standard  "internal '#ifndef'/'#define'/'#endif' approach". But it looks
>>like Brian is not satisfied with the latter. Under this circumstances, I
>>don't think he will be satisfied with any other "internal" solution.
>
> But I do not understand the problem. Only the designer of a header file
> can know if it should or should not be multiply included into a TU.
>
> Being able to write:
>
> #once
>
> at the start of a header file would solve the problem because compilers
> would then read the file the first time, mark it as read in its tables
> and not try to read it again.

Well, it all depends on the concrete specification of '#once'. BTW, if it
will work is accordance with your suggestion, it won't matter whether it is
specified at the start of a header file or in the middle of it. Note also
that in order to support this specification '#once' directive should be
always "visible" regardless of the surrounding '#ifdef'/'#endif' context,
thus outlawing such techniques as the following

  #define SUPPRESS_ONCE
  ...

  #ifndef SUPPRESS_ONCE
  #once
  #endif // SUPPRESS_ONCE

OK, as others already noted, it has been discussed to death here. I guess I
should look through previous discussions first.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]