CppCon 2015: Gabriel Dos Reis “Large Scale C++ with Modules: What You Should Know'

—
—
“Modules” are a frequently requested and long-awaited feature by C++ programmers. In a nutshell, the idea is to have a direct language support for (a) expressing the boundaries and dependencies of a program component; (b) isolating source codes from macro vagaries; (c) scaling compile time, especially for large projects, given the ubiquity of “headers-only” template libraries; (d) spur innovation and deployment of semantics-aware developer tools.

This presentation will focus on three major points: (1) the design of the module proposal currently being considered by the C++ standards committee (design goals, properties, constraints); (2) implementations currently under way; and (3) early user experience and migration.

Modules directly address a problem (scalability) listed as one of the three major areas where C++17 is expected to significantly improve daily experience of the working C++ programmer. Naturally, this feature is also on the top ten list of C++17 functionalities Bjarne Stroustrup put forward in his “Thought on C++17.”
—
Gabriel Dos Reis is a Principal Software Development Engineer at Microsoft. He is also a researcher and a longtime member of the C++ community. His research interests include programming tools for dependable software. Prior to joining Microsoft, he was Assistant Professor at Texas A&M University. Dr. Dos Reis was a recipient of the 2012 National Science Foundation CAREER award for his research in compilers for dependable computational mathematics and educational activities.
—

*-----*
*-----*

[KarlHansson]

This is by far the feature of c++ that I'm anticipating the most! It will be a huge improvement to c++. I'll be using it from day one when the experimental preview in VC++ 2015 when it arrives.

[KarlHansson]

I think you're misunderstanding what modules is. Libraries will still exist and is completely beside the point of modules. The point of modules is to improve the build system, to help enforce the one-definition-rule, to help limit the negative effects of macros. It will also provide a better situation for code analysis tools which will help with future debugging. I personally think it will make the language less complicated because of less build related headaches.

[claudiorodriguezrodriguez]

So sad to see concepts and features that are common in other languages, so awesome that this is happening.

[claudiorodriguezrodriguez]

From what I gather the point of using 'import' is to localize (or privatize) the preprocessor definitions to the module, causing reduced lookups and faster build times. import is not a replacement for #include, it is a way of keeping your code organized. Bjarne mentioned in 2014 that nobody was using namespace to modularize their code even though it was a simple and valid solution, import seems to tackle that. Gabriel states that you should put includes then imports then module defs then exports

[KarlHansson]

This is the talk I've been waiting for...

[jeroenarioni]

Will this eliminate the need of forward declarations? Because some people make data members of a class pointers so they can be forward declared and avoid an include. That is not a nice programming style imho.

[stygian]

This is all well and good but C++ made their bed when they adopted macros from C 40 years ago. I've heard multiple talks now about how bad macros are (and they are). But Gab saying that the committee doesn't want to get rid of the preprocessor anytime soon just means that all of this is good money after bad, the preprocessor IS the problem.

C++ needs to do a Python, introduce a breaking change (a huge one) to pay off all the technical debt, break away from C entirely and thereby rebuild the language in a logical, straight-forward way. Yes I know about D and Go.


P.S. Yes I know it will never happen, to many large libraries depend on preprocessor/macro abominations (Qt, Boost, any unit testing library... I actually can't think of a large, popular library that doesn't rely on it).

[MatteoSettenvini]

Unfortunately I can just get an overview of the talk, as I am busy in these days. So maybe I've just missed it.
Can someone comment on the loss of semantics in discriminating between system and user includes when transitioning from #include to the "export" keyword?
In other words, we have #include <header> and #include "header" which affect the header search path.
There are valid reasons for it (e.g. local overrides in test projects). What is the alternative when using "import"?

[GeneralBolas]

The alternative is called "I can name my modules whatever I want." Headers have to be named after files. Modules do not.

I'm not sure what "local overrides in test projects" means. But if it really matters that much, you can have a header that imports the appropriate module.

[MaherBaba]

when we finally have fast module based compilation i will dip bjarne's bald head in oil and rub it all over my body

why just don't use library? it is compiled only one, chages in library cause only recompilation of library and this comcept is alredy working ... So why add this 'modules' to language ? I thing that this feature only increase a complexity of language ....

[YourCRTube]

Great talk! IFC came as huge positive surprise!
And please do not export private members. This makes no sense.

[АндрейМилюков-рг]

Не прошло и полвека как это заметили.
Ещё полвека пройдёт, и начнут что-то делать.

[kwinzman]

using using "feet" in the presentation....

[VileLasagna]

Let's hope this is not J++ yet again.It does have promise, but I can't bring myself to trust anything coming form Microsoft when it pertains base technologies such as libraries and compilers

[ashrasmun]

I can't understand a single thing this dude says... Is he even speaking english?

[mstorer]

Keep your private life private:. Please.