Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
>Nathan Myers <ncm@nospam.cantrip.org> writes
>>Precompiled headers are a non-standard response to the problem
>>addressed in the standard with the keyword "export".
>
>I do not understand this claim.  export is about template instantiation,
>PCH were invented long before and I do not see that they do anything to
>help with the long compile/build times caused by the need to instantiate
>templates.

Of course the problem existed long before "export" was specified.
"Export" is a partial solution, dramatically reducing (but perhaps
not eliminating) the need for PCH.

The problem is long compilation times resulting from the need to
open/read/parse huge amounts of code for each compilation unit.
Whether that code is just declarations or is template definitions
doesn't much change the nature of the problem, just its size.
The template definitions are the bulk of the problem, "export"
solves that part (maybe).

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



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

Nathan Myers wrote:
>
> Greg Comeau<comeau@comeaucomputing.com> wrote:
> >Most C++ compilers support PCHs (pre-compiled headers). However, PCHs
> >are an implementation details and so the standard says nothing against
> >or for them per se.  So the thing to do is to check your compiler's
> >documentation on how they expect you to use/build/control/disable PCHs.
> >
> >And don't assume that because PCHs make sense for one project, they make
> >sense for every single compile for all your projects.  You may want to
> >check out http://www.comeaucomputing.com/4.0/docs/userman/pch.html ,
> >especially the end of it, for a general disccusion (though for a specific
> >compiler) about PCHs.
>
> Precompiled headers are a non-standard response to the problem
> addressed in the standard with the keyword "export".  I don't know
> (for sure) of any compiler that supports "export" yet.

Precompiled headers are outside the standard, but, done right, they are
not "non-standard" because they are invisible to the user, except as a
command-line switch. Their purpose is to speed up compilation, and they
make a significant difference in complex class hierarchies, whether the
classes use templates or not.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com


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

If I may be forgiven for continuing on PCH....

I have experience using PCH for Borland and Microsoft
compilers.  I found that they don't speed up compiling that
much.  I got much more of a speed enhancement by buying
a faster machine, which I'd have done anyway.

More importantly, I have found many cases where PCH
fails, and my code exhibits strange errors because older
versions of header were being used without any warning.
I no longer use PCH, for what that's worth.

Jack Klein wrote:

> In the first place, this really isn't a C++ language standards issue, so
> really doesn't belong in this newsgroup.  But since you asked...
>
> How it is implemented is liable to be rather complex.  Borland maintains that
> they actually save the state of the compiler's internal symbol table, or at
> least just the part of it that has been filled.
>

Chris Ahlstrom
major league software, llc
1259 Center Lake Dr.
Mt. Pleasant, SC 29464-7419
(843)849-0985
a h l s t r o c @bellsouth.net

If you can't be rationale, at least be reasonable.




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

Chris Ahlstrom wrote:
>
> If I may be forgiven for continuing on PCH....
>
> I have experience using PCH for Borland and Microsoft
> compilers.  I found that they don't speed up compiling that
> much.  I got much more of a speed enhancement by buying
> a faster machine, which I'd have done anyway.

Hmm, interesting. What sort of code were you compiling? Of course, when
you make changes to the headers themselves you don't get any benefit,
because the header has to be recompiled. But I've generally seen
significant speed improvements when the headers have any amount of
complexity compared to the source file itself. Even in C, if you're
compiling windows.h as part of a reasonably-sized .C file I've seen
speed increases of about an order of magnitude.

>
> More importantly, I have found many cases where PCH
> fails, and my code exhibits strange errors because older
> versions of header were being used without any warning.
> I no longer use PCH, for what that's worth.

It's certainly possible to get PCH files that don't relate to your actul
code with Microsoft's implementation, because you can tell it which file
to grab the binary version of the headers from. If you forget to update
this file you're in trouble. I have never had a problem like this with
Borland's compiler, because it handles updating the binary file
automatically.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com


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

Pete Becker <petebecker@acm.org> wrote:
>Nathan Myers wrote:
>> Greg Comeau<comeau@comeaucomputing.com> wrote:
>> >Most C++ compilers support PCHs (pre-compiled headers).
>>
>> Precompiled headers are a non-standard response to the problem
>> addressed in the standard with the keyword "export".
>
>Precompiled headers are outside the standard, but, done right, they are
>not "non-standard" because they are invisible to the user, except as a
>command-line switch. Their purpose is to speed up compilation, and they
>make a significant difference in complex class hierarchies, whether the
>classes use templates or not.

I didn't mean that an implementation which provides "precompiled
headers" (whatever that may mean) is non-conforming.  The standard
doesn't mention PCH -- just as it doesn't mention shared libraries.
Shared libraries are a non-standard feature that is fundamentally
important in real-world applications.

In other words, discussion of "export" is within the newsgroup's
charter; discussion of PCH (alone) is not.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



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

| Precompiled headers are a non-standard response to the problem
| addressed in the standard with the keyword "export".  I don't know
| (for sure) of any compiler that supports "export" yet.

I can't agree with this assessment.  Yes, templates add to the cost
imposed by the "#include" model.  But they are by no means the only
contributors.  Typical C++ programs include *huge* amounts of stuff - it
can be frightening to see just how large the output of a "pre-process
only" pass on a C++ program can be.  And then you realize that the
pre-processed file doesn't have any comments, and may very well be
missing a bunch of ifdef'ed out code!  Every byte in the expanded file
has to be read, parsed, built into internal data structures ... this
adds significant costs.

I've seen reports of factors of 10 and more speedups in compilation of
real code as the result of pre-compiling header files, including cases
where there wasn't much template code.

In fact, since the Standard's model of compilation for templates allows
- and indeed requires - that many semantic checks be delayed until the
template is instantiated, even rather large templates (and compared to
the bulk of include files out there, few templates are *that* large
anyway) probably impose relatively little in parsing costs, since only
relatively little parsing has to be done anyway.

The include model has many problems, increased compilation times being
only one.  It's a 1970's solution to a 1990's problem.  To the degree
that compilers support pre-compilation of headers, databases of pre-
compiled templates, and any other tricks they can apply - I'll applaud
them.  Unfortunately, inherent semantics of the C++ compilation model
makes this rather hard to do effectively.  Too late to change that now
(though the introduction of export did take a small, very limited, step
in the right direction).
       -- Jerry


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

In article <74841o$pon$1@shell7.ba.best.com>, Nathan Myers
<ncm@nospam.cantrip.org> writes
>Precompiled headers are a non-standard response to the problem
>addressed in the standard with the keyword "export".  I don't know
>(for sure) of any compiler that supports "export" yet.

I do not understand this claim.  export is about template instantiation,
PCH were invented long before and I do not see that they do anything to
help with the long compile/build times caused by the need to instantiate
templates.

Francis Glassborow      Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jerry Leichter <leichter@smarts.com> wrote:
>Nathan Myers wrote:
>| Precompiled headers are a non-standard response to the problem
>| addressed in the standard with the keyword "export".
>
>I can't agree with this assessment.

I'm sure you'll manage, in time.  :-)

>  Yes, templates add to the cost
>imposed by the "#include" model.  But they are by no means the only
>contributors.  Typical C++ programs include *huge* amounts of stuff - it
>can be frightening to see just how large the output of a "pre-process
>only" pass on a C++ program can be.  And then you realize that the
>pre-processed file doesn't have any comments, and may very well be
>missing a bunch of ifdef'ed out code!  Every byte in the expanded file
>has to be read, parsed, built into internal data structures ... this
>adds significant costs.

There are two problems with this argument.  First, the time spent
dealing with comments and ifdef'd-out code has been (just in my
experience) demonstrated many times to be negligible.  On some systems
the time spent just opening the header is more than the time to read
*and* parse it.

Second, when I said that the problem is "addressed" in the standard
I didn't mean that it is entirely solved.  Yes, opening and parsing
lots of non-template-definition headers wastes time.  However, the
time spent on template definitions is an order of magnitude greater,
because they are so much larger, and involve paging in much more of
the compiler.

As more and more code migrates to templates, the fraction in ordinary
headers gets much smaller.  The result is that without "export",
compilation times are much longer than old code *without* precompiled
headers.  Support for "export" brings compilation time back near where
it was (without precompiled headers).

>I've seen reports of factors of 10 and more speedups in compilation of
>real code as the result of pre-compiling header files, including cases
>where there wasn't much template code.

I don't doubt this.  Getting the OS "open()" operation to work faster
might have a similar effect.  (E.g. Linux-2.2 will have enormous
optimizations on opens, compared to most other systems, because
it turned out (also) to be a bottleneck in web servers.)

>In fact, since the Standard's model of compilation for templates allows
>- and indeed requires - that many semantic checks be delayed until the
>template is instantiated, even rather large templates (and compared to
>the bulk of include files out there, few templates are *that* large
>anyway) probably impose relatively little in parsing costs, since only
>relatively little parsing has to be done anyway.

This is not correct.  The implication for real compilers is that the
code must be parsed *twice*.  In order to get decent error messages
it must be parsed when it is read.  Not parsing all of it for each
compilation unit is a big, big win.

>The include model has many problems, increased compilation times being
>only one.  It's a 1970's solution to a 1990's problem.  To the degree
>that compilers support pre-compilation of headers, databases of pre-
>compiled templates, and any other tricks they can apply - I'll applaud
>them.  Unfortunately, inherent semantics of the C++ compilation model
>makes this rather hard to do effectively.  Too late to change that now
>(though the introduction of export did take a small, very limited, step
>in the right direction).

"export" is a small conceptual step, but it solves 90% of the current
problem.  The remaining fraction might be dealt with by precompiled-
header tricks, but they're fundamentally difficult and messy.  The
sweet spot for header optimizations is implementing "export".

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



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

 How is this accomplished, I checked the thread on "Why are C++
Compilers so slow???" and found some interesting information.  I am
relatively new to C++ so this isn't  a big deal, but I was under the
impression VC++ already did this, do the header files change much????


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

In article <3664c6ed.7813164@nntp.ne.mediaone.net> vampired@mediaone.net (Christopher) writes:
>
> How is this accomplished, I checked the thread on "Why are C++
>Compilers so slow???" and found some interesting information.  I am
>relatively new to C++ so this isn't  a big deal, but I was under the
>impression VC++ already did this, do the header files change much????

Most C++ compilers support PCHs (pre-compiled headers). However, PCHs
are an implementation details and so the standard says nothing against
or for them per se.  So the thing to do is to check your compiler's
documentation on how they expect you to use/build/control/disable PCHs.

And don't assume that because PCHs make sense for one project, they make
sense for every single compile for all your projects.  You may want to
check out http://www.comeaucomputing.com/4.0/docs/userman/pch.html ,
especially the end of it, for a general disccusion (though for a specific
compiler) about PCHs.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***


[ 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 3 Dec 1998 22:41:16 GMT, vampired@mediaone.net (Christopher) wrote:

>
>  How is this accomplished, I checked the thread on "Why are C++
> Compilers so slow???" and found some interesting information.  I am
> relatively new to C++ so this isn't  a big deal, but I was under the
> impression VC++ already did this, do the header files change much????
>

<Jack>

In the first place, this really isn't a C++ language standards issue, so
really doesn't belong in this newsgroup.  But since you asked...

Borland was the first to implement pre-compiled headers, at least in the
DOS/Windows world.  In fact I still don't know if anyone other than
DOS/Windows implementations do this.

It was Borland's response to having to compile windows.h and their OWL
application framework class library, again a first for Windows.  Microsoft
tried to quickly play catch-up but their first implementation was horribly
broken before they finally got it right.

How it is implemented is liable to be rather complex.  Borland maintains that
they actually save the state of the compiler's internal symbol table, or at
least just the part of it that has been filled.

</Jack>



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

Greg Comeau<comeau@comeaucomputing.com> wrote:
>Most C++ compilers support PCHs (pre-compiled headers). However, PCHs
>are an implementation details and so the standard says nothing against
>or for them per se.  So the thing to do is to check your compiler's
>documentation on how they expect you to use/build/control/disable PCHs.
>
>And don't assume that because PCHs make sense for one project, they make
>sense for every single compile for all your projects.  You may want to
>check out http://www.comeaucomputing.com/4.0/docs/userman/pch.html ,
>especially the end of it, for a general disccusion (though for a specific
>compiler) about PCHs.

Precompiled headers are a non-standard response to the problem
addressed in the standard with the keyword "export".  I don't know
(for sure) of any compiler that supports "export" yet.

Most discussions of "export" seem to assume that it must be
implemented in a way that is unnaturally difficult.  However,
it need not be much more complicated than creating a regular
library archive, with a similar amount of help from the user
both in creating and in using it.

The practical difficulty is mainly in sharing the "context", i.e.
the set of declarations included before each exported definition,
among the various definitions.  You don't need that kind of context
in an object file library.  The context would generally be large
enough to make such sharing necessary.

The shared context would occupy a place in the template archive
similar to the place of the symbol table in an object archive.
Probably the ELF format can be extended to represent template
archives.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



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