Modules, componentization, and transition

[Gabriel Dos Reis]

See attached. I will upload a copy to EWG wiki.
Feedback welcome.

Thanks,

-- Gaby

[Gerardo Hernandez]

Hi Gabriel,

I have been giving some thought to the papers. The preprocessor and the rest of C++ are basically two different languages, the preprocessor is a code generator and the rest (phases 5 to 9) are the fundamental C++ compiler. Today, C++ needs the preprocessor to create any useful program. And to me, modules are a first to step to remove that dependency from the preprocessor (at least in the Visual C++ implementation, as #includes would disappear). 

I would like to write my own C++ code without a preprocessor. That is why I would like to see (or propose) how all those dependencies from the core C++ to the preprocessor are removed, so in the future I would be able to write C++ that does not require the preprocessing stages (1-4) thus compiling much faster.

As the paper suggests, we cannot just remove the preprocessor from the language because of the existing code. But, in my opinion, we should find ways of removing all the dependencies the language has from the preprocessor, so developers could write new C++ projects without the use of a preprocessor, and they will still be able to use the preprocessor, but just in case there is some kind of legacy dependency.

In terms of implementations, I think the LLVM, as a generalization of precompiled headers, can be a good solution in the meantime, but the Visual C++ implementation is where the language should be really headed (still waiting to try the VC++ modules myself, of course), because is a step towards making the preprocessor non-essential.

There is one aspect of modules that I do not see many comments about: they introduce concurrency in the compilation process. I.e. in the current model every .cpp can be compiled completely independently of the others, there are no dependencies. Modules introduce dependencies and thus the need for synchronization. For instance, I have tried compiling a large codebase (the boost libraries) using make -j and the clang 3.8 compiler, with modules enabled, and I was a bit surprised to see that the module "std" was compiled multiple times. One would expect std to be compiled just once per cache instance.

Thanks for you work Gabriel, and I would be more than happy to go deeper into these thoughts of reducing the dependency to the preprocessor.

[Lawrence Crowl]

On 10/5/15, Gabriel Dos Reis <g...@microsoft.com> wrote:
> See attached. I will upload a copy to EWG wiki.
> Feedback welcome.

To scale, a module system should not export the transitive closure of
declarations. For example, consider a module A that imports module B
to obtain a parameter type T for the declaration of a function F. If
module Z imports A but does not import B, then module Z should see
neither T nor F.

To scale, a module system cannot provide macros. This means that
Unix/C/C++ headers must be re-engineered to be module friendly. The
assert.h header must die for C++ to live.

--
Lawrence Crowl

[Gabriel Dos Reis]

Imports are not transitive by default.
However, it ought to be possible for a component designer to *explicitly* re-export whatever modules she deems necessary.

--
You received this message because you are subscribed to the Google Groups "SG2 - Modules" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modules+u...@isocpp.org.
To post to this group, send email to mod...@isocpp.org.
Visit this group at https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fgroups.google.com%2fa%2fisocpp.org%2fgroup%2fmodules%2f.&data=01%7c01%7cgdr%40microsoft.com%7cf310273e86bb46991e1d08d2d38eea53%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=hsCA%2fBX38KgSxW7PXbdkiMcKZ0EZUoH71HRyyXuvzrs%3d