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 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 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 "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
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 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
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
parent reply 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
next sibling parent reply 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
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 parent reply 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
next 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
next sibling 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 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 "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 reply "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.



scope at least in future versions of module system.
Nov 20 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/20/2012 6:36 PM, xenon325 wrote:


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


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


 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
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
parent reply 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
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 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 reply "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
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 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