On 11/20/2012 6:36 PM, xenon325 wrote:
> On slide #39 there is `public:`. So I guess they consider module scope at least
> in future versions of module system.

True, but I was thinking of what happens when module A defines public X, and module B defines public X. Then A and B are imported.

On 2012-11-21 01:41, Walter Bright wrote:

> 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

Note that headers are only needed for backwards compatibility. Check slides 38-42, especially slide 42: "No headers!".

So if you start a new project with Clang and don't need backwards compatibility or compatibility with any other compiler/library you don't need headers.

-- 
/Jacob Carlborg

On Wednesday, 21 November 2012 at 00:08:05 UTC, Leandro Lucarella wrote:
> Jonathan M Davis, el 20 de November a las 14:45 me escribiste:
>> On Tuesday, November 20, 2012 23:32:47 Paulo Pinto wrote:
>> > Am 20.11.2012 21:57, schrieb Walter Bright:
>> > > Since people already use precompiled headers with C++, I don't think
>> > > this change has much chance of making it compile faster.
>> > 
>> > Is it really so?
>> > 
>> > I would expect that with proper modules C++ compilers could achieve
>> > compile times similar to what other module based languages offer.
>> > Specially if templates are also stored in a module friendly format.
>> > 
>> > But then again I lack enough compiler development experience to be able
>> > to judge that.
>> > 
>> > Assuming you're right, then C++ is really a lost cause, and the current
>> > trend of standards might follow what happened to Extended ISO Pascal,
>> > which vendors ignored in favour of Turbo Pascal as the defacto standard.
>> 
>> You should read this:
>> 
>> http://www.drdobbs.com/cpp/c-compilation-speed/228701711
>> 
>> It's an article by Walter explaining why C++ compilation speeds are so slow. Pre-compiled headers would help in some circumstances, but in others, they can't (because recompilation is required due to different preprocessor macros or whatnot).
>
> 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.
>
> 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.
>
> Thanks :)

That is my understanding as well.

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.