Worth remembering that the C++ standards committee hasn't yet drawn up a spec for modules. These are MSVC only for now. Clang has its own implementation.
According to MS' blog post, this is based on the current modules proposal that the committee is working on. Isn't Clang also following the same proposal?
There are two competing proposals before the committee currently. Microsoft is implementing one of them, clang is driving the other.
By pursuing implementations of different proposals the committee hopes to converge on a best compromise design incorporating lessons learned from trying them out in practice.
curious - I remember when modules were first proposed I thought Apple was heading up the initiative, based on their work with Objective-C. I remember reading slides someone at Apple prepared describing the likely syntax and everything...
"According to MS' blog post, this is based on the current modules proposal that the committee is working on. Isn't Clang also following the same proposal?"
The blog post is just oddly written to make it seem like the proposal MS has implemented was approved.
Not sure why it was done, but it's confusing.
They do make sure to remind you that it is an experimental implementation, which you need to specifically turn on. Definitely not a good idea to write significant amounts of code based on experimental stuff.
Microsoft's C++ people are good now, and heavily involved in the standards process. Their eventual non-experimental version of modules will conform to whatever the spec is.
"Modules are often talked about as a way to speed up compilation."
How much do modules help compilation speed? This was supposedly one of the reasons Go compiles fast. Swift has modules but I don't believe that it has fast compilation.
For C++, the major speed improvement of modules would probably come with not having to parse a giant header (after preprocessing) again and again and again and again. That is not a problem ever in other languages, so comparison may be meaningless.
I'll echo netheril96, but it's perhaps worth mentioning that for very large projects, especially if they are likely to be compiled on a weak machine, it can reduce compilation times by limiting the size of the symbol table.
Swift 2 compiles much faster than Swift 1. I'm not sure I'd call it "fast" yet, but I no longer have time for a coffee break when doing a complete rebuild of a reasonably large project.
Those of us on Apple platforms have been using modules for a while now.
They help a ton because an imported module has a pre-baked interface, not a huge set of header files that get copied and pasted (from the compiler's point of view). You cant break the module's header with a funky macro either.
14 comments
[ 3.3 ms ] story [ 47.4 ms ] threadBy pursuing implementations of different proposals the committee hopes to converge on a best compromise design incorporating lessons learned from trying them out in practice.
Slightly more info in this write up of the Oct 2015 meeting https://botondballo.wordpress.com/2015/11/09/trip-report-c-s...
The blog post is just oddly written to make it seem like the proposal MS has implemented was approved. Not sure why it was done, but it's confusing.
Microsoft's C++ people are good now, and heavily involved in the standards process. Their eventual non-experimental version of modules will conform to whatever the spec is.
How much do modules help compilation speed? This was supposedly one of the reasons Go compiles fast. Swift has modules but I don't believe that it has fast compilation.
They help a ton because an imported module has a pre-baked interface, not a huge set of header files that get copied and pasted (from the compiler's point of view). You cant break the module's header with a funky macro either.