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