www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - [OT] Clang seems to implement modules

reply Jacob Carlborg <doob me.com> writes:
I just read the slides of a talk from that latest LLVM Developers' 
Meeting. It's a talk about modules by Doug Gregor from Apple. It seems 
that they already have started to implement this new feature in Clang.

-- 
/Jacob Carlborg
Nov 17 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:

 I just read the slides of a talk from that latest LLVM 
 Developers' Meeting. It's a talk about modules by Doug Gregor 
 from Apple. It seems that they already have started to 
 implement this new feature in Clang.

It's from the conference I have recently linked two slide packs here. The slides you refer are: http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf Bye, bearophile
Nov 17 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-17 12:30, bearophile wrote:

 It's from the conference I have recently linked two slide packs here.
 The slides you refer are:

 http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf

Thanks, I forgot the link. -- /Jacob Carlborg
Nov 17 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/17/2012 3:30 AM, bearophile wrote:
 http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf

One thing to note what it doesn't do - it doesn't produce a "module" scope. As far as I can tell, the symbols in imported modules all go into the global scope. It seems to be mainly a way of legitimizing precompiled headers.
Nov 19 2012
next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2012-11-19 20:43:22 +0000, Walter Bright <newshound2 digitalmars.com> said:

 On 11/17/2012 3:30 AM, bearophile wrote:
 http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf

One thing to note what it doesn't do - it doesn't produce a "module" scope. As far as I can tell, the symbols in imported modules all go into the global scope. It seems to be mainly a way of legitimizing precompiled headers.

It's better semantically than precompiled headers because you're importing symbols only from the modules you import, not those from modules imported indirectly. Just that would be an incredible cleanup. It seems there are actually two models: you can make modules from existing headers (by writing module maps), or you can create modules directly by starting your .c/.cpp file with "export <module name>;" as can see on the Writing a Module slide. The former approach is introduced as the transitional model, the later as the futuristic one that requires no headers. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Nov 19 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/19/2012 6:11 PM, Michel Fortin wrote:
 On 2012-11-19 20:43:22 +0000, Walter Bright <newshound2 digitalmars.com> said:

 On 11/17/2012 3:30 AM, bearophile wrote:
 http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf

One thing to note what it doesn't do - it doesn't produce a "module" scope. As far as I can tell, the symbols in imported modules all go into the global scope. It seems to be mainly a way of legitimizing precompiled headers.

It's better semantically than precompiled headers because you're importing symbols only from the modules you import, not those from modules imported indirectly. Just that would be an incredible cleanup.

I know. I just pointed this out as I suspect this will not improve compile times more than precompiled headers do.
 It seems there are actually two models: you can make modules from existing
 headers (by writing module maps), or you can create modules directly by
starting
 your .c/.cpp file with "export <module name>;" as can see on the Writing a
 Module slide. The former approach is introduced as the transitional model, the
 later as the futuristic one that requires no headers.

They could dub them ".ci" files <g>.
Nov 19 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-20 04:01, Walter Bright wrote:

 I know. I just pointed this out as I suspect this will not improve
 compile times more than precompiled headers do.

The compiler will compile the header and create a some kind of map file from it. This map file will be cached and later used during the compilation process. I don't know how this compares to precompiled headers. -- /Jacob Carlborg
Nov 19 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/19/2012 11:17 PM, Jacob Carlborg wrote:
 On 2012-11-20 04:01, Walter Bright wrote:

 I know. I just pointed this out as I suspect this will not improve
 compile times more than precompiled headers do.

The compiler will compile the header and create a some kind of map file from it. This map file will be cached and later used during the compilation process. I don't know how this compares to precompiled headers.

It's really what precompiled headers are.
Nov 20 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/20/2012 4:33 AM, Paulo Pinto wrote:
 On Tuesday, 20 November 2012 at 09:53:31 UTC, Walter Bright wrote:
 On 11/19/2012 11:17 PM, Jacob Carlborg wrote:
 On 2012-11-20 04:01, Walter Bright wrote:

 I know. I just pointed this out as I suspect this will not improve
 compile times more than precompiled headers do.

The compiler will compile the header and create a some kind of map file from it. This map file will be cached and later used during the compilation process. I don't know how this compares to precompiled headers.

It's really what precompiled headers are.

Except there is no standard way of doing it.

Exactly, hence my comment about it "legitimizing" them.
 The work being paved by clang as base for the C++ modules, is a way to use map
 files as transition into a full module system.

 It is to be expected that if C++17 gets modules, and C++ by that time still
 matters, header and map files could possibly be ditched way (deprecated) in the
 following standard.

 Personally I hope that in 2017 we already something much better in place, like
 D. :)

Since people already use precompiled headers with C++, I don't think this change has much chance of making it compile faster.
Nov 20 2012
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
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. -- Paulo
Nov 20 2012
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/20/2012 2:45 PM, Jonathan M Davis wrote:
 http://www.drdobbs.com/cpp/c-compilation-speed/228701711

One thing I neglected to mention is that template instantiation is terribly, fundamentally, slow. This problem comes to the fore when templates are used to implement computations, such as doing a compile time factorial using a template. No amount of module design can possibly fix that. D fixes it by using CTFE for compile time computations. (You can still do it with templates, but you'll be sorry.) CTFE is still slow, but it's a hundred times (made up number) faster than using templates.
Nov 20 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 20 2012
parent Jacob Carlborg <doob me.com> writes:
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
Nov 20 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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). And there are issues intrinsic to the lanugage which make compilation slower even if you were able to compile each file only once. C/C++ are just plain badly designed when it comes to compilation speed. Textual inclusion is a horrible idea in that regard (though it may have been required at the time those languages were created due to the memory constraints of the systems at the time). So, while smart people may be able to make some improvements to C++ to shorten compilation times (and we all hope that they succeed), they can never entirely fix them. For that, among other things, you'd need a language which didn't use textual inclusion, and those sorts of changes would be too big for C/C++ at this point. I think that that's on the list of changes which are pointless to make to C/C++, because if you were going to break backwards compatibility on that level, you might as well just create a new language. The challenge that the C/C++ folks have is improving it without breaking backwards compatibility, and that's incredibly constraining, since so many of C/C++'s problems are very intrinsic to how they're designed. - Jonathan M Davis
Nov 20 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 CTFE is still slow,

I don't agree. Given that what's run at compile-time is statically typed code that's easy to optimize, then with techniques that are simpler that ones used by LuaJIT CTFE or JavaScript V8 JIT (that work on dynamically tyed code, that requires lot of work to optimize well), it is able to become almost as fast as regular D code (such JITs compile only if a computation/loop takes a large enough amount of time, otherwise they interpret efficiently). Bye, bearophile
Nov 20 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
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.
Nov 21 2012
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
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.
Nov 21 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 20 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/17/12, bearophile <bearophileHUGS lycos.com> wrote:
 http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf

Page 36: import std.stdio; Hmm. :)
Nov 17 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
Is it a good idea to reuse local modules in debugger? The 
debugged code can be compiled with a different version of module.
Nov 17 2012
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 17.11.2012 12:03, schrieb Jacob Carlborg:
 I just read the slides of a talk from that latest LLVM Developers'
 Meeting. It's a talk about modules by Doug Gregor from Apple. It seems
 that they already have started to implement this new feature in Clang.

Thanks for the heads up. I remember reading his early work, and how C and C++ might add these extensions into the standards, depending on how clang experience goes. Getting modules into C and C++ might be a feature less in D versus those languages comparisasion, but it will increase the lives of those that have to use them. -- Paulo
Nov 17 2012
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 17 November 2012 at 11:03:18 UTC, Jacob Carlborg 
wrote:
 I just read the slides of a talk from that latest LLVM 
 Developers' Meeting. It's a talk about modules by Doug Gregor 
 from Apple. It seems that they already have started to 
 implement this new feature in Clang.

It's about time... I honestly cannot believe that this wasn't #1 priority for C++11. Everyone that uses C++ for a living knows that compilation time is the biggest practical problem with C++, yet the standards committee seems completely unaware of this. Herb Sutter posted a poll recently asking what people wanted most from their C++ compiler. In the poll options he had things such as conformance, safety, runtime performance, but didn't even think to add compile time performance. Of course, everyone in the comments wasn't pleased with this. http://herbsutter.com/2012/10/03/poll-what-features-would-you-like-to-see-added-soonest-in-your-favorite-c-compiler/ I get the feeling that the C++ standards committee was formed to serve Boost developers.
Nov 18 2012
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 18.11.2012 18:51, schrieb Peter Alexander:
 On Saturday, 17 November 2012 at 11:03:18 UTC, Jacob Carlborg wrote:
 I just read the slides of a talk from that latest LLVM Developers'
 Meeting. It's a talk about modules by Doug Gregor from Apple. It seems
 that they already have started to implement this new feature in Clang.

It's about time... I honestly cannot believe that this wasn't #1 priority for C++11. Everyone that uses C++ for a living knows that compilation time is the biggest practical problem with C++, yet the standards committee seems completely unaware of this. Herb Sutter posted a poll recently asking what people wanted most from their C++ compiler. In the poll options he had things such as conformance, safety, runtime performance, but didn't even think to add compile time performance. Of course, everyone in the comments wasn't pleased with this. http://herbsutter.com/2012/10/03/poll-what-features-would-you-like-to-see-added-soonest-in-your-favorite-c-compiler/ I get the feeling that the C++ standards committee was formed to serve Boost developers.

Sometimes I feel the same. Nowadays I work mostly with JVM/.NET languages and every time I do something in C++, I really hate the compile times. I really don't understand why no one added modules to C and C++, taking into consideration that the other systems programming languages of the time already had them. -- Paulo
Nov 18 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/18/2012 12:17 PM, Paulo Pinto wrote:
 I really don't understand why no one added modules to C and C++, taking into
 consideration that the other systems programming languages of the time already
 had them.

There was a proposal to add modules to C++11, but it failed to gather much interest.
Nov 18 2012
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/18/2012 1:20 PM, Jonathan M Davis wrote:
 Honestly, it's the sort of thing that I would have thought wouldn't even be
 possible in C++,

I haven't read the proposal, but it is feasible.
Nov 18 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-19 10:58, Paulo Pinto wrote:

 I don't see what it would break, besides the pre-processor usage.

Exactly: "‘import’ ignores preprocessor state within the source file". But what I don't understand is that on a few slides later it says: "What Does import Import?" And: "Functions, variables, types, templates, macros, etc." Note it says "macros".
 Modules mean that the compilers just need to read a symbol table
 or an AST from an external file.

That's basically how it works: 1. Find a module map for the named module 2. Spawn a separate instance of the compiler: 2a. Parse the headers in the module map 2b. Write the module file 3. Load the module file at the ‘import’ declaration 4. Cache module file for later re-use I think this is only to be compatible with pre-existing headers. -- /Jacob Carlborg
Nov 19 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, November 18, 2012 12:53:59 Walter Bright wrote:
 There was a proposal to add modules to C++11, but it failed to gather much
 interest.

Honestly, it's the sort of thing that I would have thought wouldn't even be possible in C++, because it would require too much of a redesign and would break backwards compatibility. There a lot of things like that in C++ which are completely unfixable without breaking backwards compatibility, and if you're doing that, you might as well go all the way and create a new language, since there are so many things that should be fixed/changed that it wouldn't really be C++ anymore by the time that you were done (it would probably be something much closer to D). It'll be interesting to see how they actually implement a module feature. Also, I think that so many C/C++ devs are so used to the compile times that they get with them that it's nowhere near the top of the list of features that they want. It probably didn't even occur to many of them. Not to mention, if you think that fixing the problem isn't really even feasible (and I have no idea how it's feasible as long as the pre-processor or textual inclusion is involved), then it's definitely not going to be on the list of things that you're asking for. - Jonathan M Davis
Nov 18 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 18 November 2012 at 21:21:12 UTC, Jonathan M Davis 
wrote:
 Also, I think that so many C/C++ devs are so used to the 
 compile times that
 they get with them that it's nowhere near the top of the list 
 of features that
 they want. It probably didn't even occur to many of them. Not 
 to mention, if
 you think that fixing the problem isn't really even feasible 
 (and I have no
 idea how it's feasible as long as the pre-processor or textual 
 inclusion is
 involved), then it's definitely not going to be on the list of 
 things that
 you're asking for.

Check the comments in the post I linked to. It's at the top of just about everyone's list (except Herb's, apparently).
Nov 18 2012
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 18 November 2012 at 21:21:12 UTC, Jonathan M Davis 
wrote:
 On Sunday, November 18, 2012 12:53:59 Walter Bright wrote:
 There was a proposal to add modules to C++11, but it failed to 
 gather much
 interest.

Honestly, it's the sort of thing that I would have thought wouldn't even be possible in C++, because it would require too much of a redesign and would break backwards compatibility. There a lot of things like that in C++ which are completely unfixable without breaking backwards compatibility, and if you're doing that, you might as well go all the way and create a new language, since there are so many things that should be fixed/changed that it wouldn't really be C++ anymore by the time that you were done (it would probably be something much closer to D). It'll be interesting to see how they actually implement a module feature.

I don't see what it would break, besides the pre-processor usage. Modules mean that the compilers just need to read a symbol table or an AST from an external file.
 Also, I think that so many C/C++ devs are so used to the 
 compile times that
 they get with them that it's nowhere near the top of the list 
 of features that
 they want. It probably didn't even occur to many of them.

This is why so many developers with C and C++ only experience think Go compile times are great, when every developer outside C and C++ world has been having them for the last 30 years.
 Not to mention, if
 you think that fixing the problem isn't really even feasible 
 (and I have no
 idea how it's feasible as long as the pre-processor or textual 
 inclusion is
 involved), then it's definitely not going to be on the list of 
 things that
 you're asking for.

 - Jonathan M Davis

Easy, just do them the same way as Turbo Pascal/Delphi do it. If you really need to change the pre-processor values, then you need to recompile the module anyway. http://www.freepascal.org/docs-html/prog/progse1.html#progsu37.html This is the same thing D requires, if the version() values change, right? -- Paulo
Nov 19 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Sunday, 18 November 2012 at 17:51:25 UTC, Peter Alexander 
wrote:
 I get the feeling that the C++ standards committee was formed 
 to serve Boost developers.

Not that this means anything sinister represents a conflict of interest, but ... http://www.boost.org/users/faq.html Is there a formal relationship between Boost.org and the C++ Standards Committee? No, although there is a strong informal relationship in that many members of the committee participate in Boost, and the people who started Boost were all committee members. --rt
Nov 19 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 20 November 2012 at 09:53:31 UTC, Walter Bright wrote:
 On 11/19/2012 11:17 PM, Jacob Carlborg wrote:
 On 2012-11-20 04:01, Walter Bright wrote:

 I know. I just pointed this out as I suspect this will not 
 improve
 compile times more than precompiled headers do.

The compiler will compile the header and create a some kind of map file from it. This map file will be cached and later used during the compilation process. I don't know how this compares to precompiled headers.

It's really what precompiled headers are.

Except there is no standard way of doing it. The work being paved by clang as base for the C++ modules, is a way to use map files as transition into a full module system. It is to be expected that if C++17 gets modules, and C++ by that time still matters, header and map files could possibly be ditched way (deprecated) in the following standard. Personally I hope that in 2017 we already something much better in place, like D. :) -- Paulo
Nov 20 2012
prev sibling next sibling parent "DypthroposTheImposter" <mcbracket gmail.com> writes:
  I'd expect it to outperform pre-compiled headers, with PCH you 
can only add certain headers that you rarely change, since they 
all get packaged up into a single glob(sloow).  With this new 
module stuff you effectively get PCH for each module separately, 
so even files that are changed often will benefit from PCH.

  And no more dicking around with PCH and having to include 
'sdffx' everywhere etc..
Nov 20 2012
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
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 :) --
Nov 20 2012
prev sibling parent "xenon325" <1 a.net> writes:
On Monday, 19 November 2012 at 20:43:21 UTC, Walter Bright wrote:
 On 11/17/2012 3:30 AM, bearophile wrote:
 http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf

One thing to note what it doesn't do - it doesn't produce a "module" scope. As far as I can tell, the symbols in imported modules all go into the global scope. It seems to be mainly a way of legitimizing precompiled headers.

On slide #39 there is `public:`. So I guess they consider module scope at least in future versions of module system.
Nov 20 2012