Re: #pragma once in ISO standard yet?
On Dec 18, 10:18 pm, Andre Kaufmann <akfmn...@t-online.de> wrote:
James Kanze wrote:
[...]
Interestingly enough, I think just the opposite would be the
effect. The compiler must somehow find the interface
specifications, if it is to check them.
Yes and no ;-). The compiler must only compile them once and stores the
interfaces and code in a preparsed binary format and compile the
implementations (if possible).
You mean pre-compiled headers:-). In fact, of course, the
pre-processor works against this; the actual meaning of a header
depends on the macros which are defined when it is included.
Otherwise... I'm all for compiling the specification, and using
the compiled version.
At least it's done this way by the other
languages. But in the other languages (Java, Delphi) you too specify
which files to import or use. An exception is only C#. And yes, it tends
to compile more files perhaps as the other languages and may be it
compiles all files again, if there isn't a smart background compiler
keeping track of the changes.
The trick is, it is still faster in compiling all sources, than the C++
compiler in compiling a single one. ;-).
That's because they don't support template meta-programming:-).
And there basic IO isn't a template, which needs
instantiation:-). Seriously: the preprocessor doesn't speed
things up, and templates with all of the implementation in the
headers, for something as large as <iostream>, slows things up
significantly, even if you only read the file once. If you're
on a Unix machine, try something like: "CC -E hello.cc | wc -l",
where hello.cc is the classical hello, world program. And if
you can, then go back and try it with a compiler using the
classical iostream (which weren't templates). I get 12223 for
the standard version, 1609 for the one with the classical
iostream. That goes a long way in explaining the difference in
compile times.
I admit I haven't checked how C# performs when the sources are located
on a network path or in very large projects. You then perhaps have to
build libraries in binary form.
In C++ the compiler doesn't (normally) precompile any code, but inserts
the header files every time in textual form and recompiles it again and
again. I hope that this could change, when modules are supported in C++.
That's part of the purpose of modules, I think. Still...
A lot more could be done than is. There's nothing in the
standard which would preclude a compiler having an option to
"package" a library: wrap it up in a package with all of the
object files AND all of the headers (pre-compiled, of course),
and have the compiler look there when it encounters an include.
In theory, it's difficult because of the pre-processor, and you
might end up needing several versions of the headers, or perhaps
needing some sort of preconditions involving macros, and a copy
of the text to fall back on if the preconditions failed.
The problem, in general, is that in C++, including exactly the
same text doesn't guarantee that you end up with the same thing.
Mainly because of the preprocessor, although you can also play
games with typedef's and other such things. I think, however,
that it is doable, possibly by introducing some restrictions on
how macros are used in the headers. (A compiler could introduce
the restrictions, as long as the older system still worked when
they weren't met.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S9mard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
---
[ 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.comeaucomputing.com/csc/faq.html ]