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

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.

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

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

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

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/

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

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

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.