View mode: basic / threaded / horizontal-split · Log in · Help
November 21, 2012
Re: [OT] Clang seems to implement modules
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.
November 21, 2012
Re: [OT] Clang seems to implement modules
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
November 21, 2012
Re: [OT] Clang seems to implement modules
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.
November 21, 2012
Re: [OT] Clang seems to implement modules
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.
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home