
A Module System for C++ (Revision 2) [pdf] - lelf
http://isocpp.org/files/papers/n4214.pdf
======
haberman
Is this a path to standardization for the modules work that's been in progress
from the Clang guys? Or something different?

[http://clang.llvm.org/docs/Modules.html](http://clang.llvm.org/docs/Modules.html)

~~~
pjmlp
Partially, the Clang guys took ownership of the modules design group and are
responsible for prototyping it.

This doesn't mean the standard will be 1:1 to what Clang currently offers.

------
acqq
The major reason of the awfully slow compilation (and linking) of the bigger
C++ projects is all the templates in the stl or (deity forbids) boost that are
used in every compilation unit. So I'd like to know if using this new "sugar"
can make the compilation of the existing programs faster once the compiler and
linker are made to recognize that sugar. Skimming through the pdf, I wasn't
able to figure out from where the speed up is supposed to come. "Compiled
once" in the object code sense doesn't matter for stl or boost since
everything is in headers: there's simply no object code until you start to
compile the cpps which include the headers. Can anybody explain what they are
trying to do? Are they attempting to solve the templates problem or are they
effectively just making a new form of the "lib" files?

~~~
mattnewport
At a minimum this can give you a much better and more modular version of
precompiled headers. Because modules are guaranteed not to be affected by
macros or ordering of module imports in the importing translation units you
can get a modularized version of precompiled headers.

Don't underestimate the cost of just reading in all that text and parsing it.
Modules allow you to cache some pre-parsed AST or similar internal
representation of any exported template definitions which should greatly
reduce the cost of instantiating them in the importing translation unit due to
savings in IO and parsing time. Importantly, importing translation units never
even have to look at definitions they don't use whereas currently they have to
fully parse everything that gets dragged in by the headers they include even
if they only use a tiny subset of the functionality.

A module enabled STL with well implemented compiler and linker support should
greatly reduce build times for codebases that make heavy use of STL by simply
replacing #include <header> with import std.header. The proposal eliminates
all the unnecessary overhead of templates (re-parsing huge amounts of text)
and leaves only the necessary / desirable overhead (instantiation from some
internal representation with the specific types used). It's that final
instantiation that gives templates their runtime performance advantages over
other models (like C# generics) so you wouldn't want to lose that.

~~~
lomnakkus
Exactly. Essentially this reduces the _algorithmic complexity_ of compilation
which is a huge boon given that even simple programs these days result in the
(repeated) parsing of _millions_ of lines of code. Instantiation of templates
obviously won't change, but recursive traversal and repeated re-parsing of
includes will be completely unnecessary as the compiler can _trivially_ [1]
cache the intermediate version. Which is as it should have been from the
start, but then hindsight is 20-20.

It's really an elegant solution considering the constraints they're working
under.

[1] Preprocessor macros don't leak from includ _ers_ to includ _ees_ , so
headers become independent of each other.

------
ttt123
This is useless syntactic sugar unless there is a forward compatible ABI with
comes with it. That includes modules being able to use different versions of a
dynamically linked libstdc++, i.e. modules compiled with different compiler
versions. Which will never happen given the resistance from compiler folks to
agree on a standard ABI.

~~~
golemotron
This. And the reason that C++ compilation is so painfully slow is that unlike
languages who saw C++'s problems and corrected them (Java, C#), a C++ compiler
can not glean definitions from compiled code.

In Java, the compiler reads a Java file once, produces a class file and the
class file contains all the information needed to compile other files that
refer to its contents.

In C++, the compiler has to read all of source declarations that are used by a
compilation unit, over and over again. An arbitrary cpp file can transitively
include tens to hundreds of header files. Modern C++ compilers can play
caching tricks, but the model is intrinsically O(n^2) compilation rather than
O(n) compilation where n is the number of source files.

~~~
WalterBright
There are a lot of reasons why compiling C++ is inherently slow, but one big
one is having a text preprocessor implementing an entirely different language
tacked on the front.

------
kazinator
The short story is that a "module" should be approximately the same thing as a
"compilation unit". (Not a compilation unit, plus some fragmented-off textual
header file.). Secondly, information about the public interface of that
compilation unit must somehow be marked off, and provided for the compilation
of dependent modules.

A more digestible description of this can be found in a Modula 2 reference
manual:

[http://www.modula2.org/reference/modules.php](http://www.modula2.org/reference/modules.php)

The Modula 2 compiler I worked with years ago simply had you put the
definition modules into .def files and the implementation modules into .mod
files. So it's vaguely like headers, except that the .def files have structure
and can be compiled; the compiled info is then referenced during compilation
of the client modules. The .def file is never directly referenced as text.

~~~
pjmlp
Modules go at least all the back to Algol 68 and Mesa, but C designers choose
to ignore them.

C++ design goal of being able to target unmodified C toolchains as a means of
being accepted by C developers, meant C++ also had to keep away from modules.

Luckily C++ can stand on its own nowadays and depart from such decisions.

------
72deluxe
Fascinating reading as usual. The C++ articles that get posted on here really
are enlightening.

------
aldanor
Module system, uniform function call syntax (UFCS) -- it all starts looking
more and more like D :)

------
pjmlp
I just wonder, if waiting until C++17 gets done and available across all major
compilers in all platforms, not just the C++ triad that gets discussed on HN,
won't be a kind of "too little, too late" kind of thing.

~~~
kyberias
What is your point? And what is "C++ triad"?

~~~
repsilat
Possibly g++, clang and MSVC? Or Linux, Windows and OS X?

~~~
pjmlp
Both.

There are lots of compilers and OS out there besides those.

Which are what get discussed here most of the time.

~~~
GFK_of_xmaspast
There's what, Portland, Wind River, ????? I heard intel's wrapped around clang
these days.

~~~
jzwinck
Here are some:

[http://en.wikipedia.org/wiki/Oracle_Solaris_Studio](http://en.wikipedia.org/wiki/Oracle_Solaris_Studio)

[http://en.wikipedia.org/wiki/HP_aC%2B%2B](http://en.wikipedia.org/wiki/HP_aC%2B%2B)

[http://en.wikipedia.org/wiki/IBM_XL_C%2B%2B](http://en.wikipedia.org/wiki/IBM_XL_C%2B%2B)

Notably, each of those can target an OS and hardware architecture made by the
same vendor (Sun Solaris/SPARC, HP UX/PA-RISC, IBM AIX/POWER).

------
haridas
The specification looks familiar to python and go.. how it will handle
backward compatibility ?

