On Wednesday, 21 November 2012 at 00:41:39 UTC, Walter Bright
wrote:
On 11/20/2012 3:51 PM, Leandro Lucarella wrote:
Did you ever cared about reading those slides?!?!? You keep
talking about
problems with pre-compiled headers and what Doug Gregor is
suggesting are NOT
pre-compiled headers. Those are already in clang AFAIK.
What he is proposing is a real module system, macros will not
be re-evaluated
inside modules. The symbols being global have nothing to do
with this being
pre-compiled headers.
Modules *are* a form of precompiled headers.
Will this solve all the problems from C++ and make its compile
time blazingly
fast? Probably not, but will sure help, not only to avoid
reading the same
header over and over, but also by saving memory. But one thing
is certain,
THIS IS NOT PRE-COMPILED HEADERS (he even mention pre-compiler
headers in the
slides).
For f*ck sake... Please, stop this misinformation madness.
Precompiled headers are:
1. compile a bunch of .h files into a symbol table
2. cache the symbol table (in memory or on disk)
3. read the symbol table instead of reparsing the .h files
Modules are:
1. compile a bunch of .h files into a symbol table
2. cache the symbol table (in memory or on disk)
3. read the symbol table instead of reparsing the .h files
Yes, I understand that there are semantic differences, and many
differences in detail. C++11 does not support precompiled
headers; all ph implementations are a kludge and are not
standard compliant. The module proposal "legitimizes" them,
i.e. changes the standard so that ph can be compliant. Yes,
additional goodies are added like a separate scope for macros,
an explicit syntax for them, etc.
The speed improvement should be comparable to what can be
achieved with a good ph system.
Ada and Modula-3 compile relatively fast, even when making use
of generics.
That is why I think using proper modules would be faster than
what is possible with pre-compiled headers.
But as refereed on my previous post, I am not a compiler expert,
so my assumption might be wrong.
Is this module proposal an improvement? I'd say yes. Is it
going to solve C++'s compile speed problems? I doubt it. Is it
a "true" module system? I don't know about that, but it doesn't
address things like name collisions that are imported from
different modules, at least not from what I saw in the slides.
That would be solvable by namespaces, I imagine.
