A Module System for C++ (Revision 2) [pdf]

http://isocpp.org/files/papers/n4214.pdf

by lelf • 12 years ago

80 42 12 years ago

pjmlp10• 12 years ago

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.

ben0x5392• 12 years ago

I think people who are invested in C++ now won't suddenly stop being invested in it by the time C++17 rolls around.

pjmlp10• 12 years ago

Many people are invested in C++, because in the last 20 years there was an investment in VM based runtimes, effectively leaving C and C++ as the only to go languages if one was looking for ahead of time compilation[0].

Now with Java and .NET upcoming adoption of ahead of time compilation to native code in the next versions.

Additionally with other languages like D, Rust, Go, Swift, Ada, Haskell, OCaml fighting for a place at the Sun.

There will be lots of options for those looking into languages with support for ahead-of-time compilation to native code in their reference implementations.

Thus pushing C++ deeper into the OS realm, while at the same time giving to those people other options to look for.

Hence my remark.

[0] There were other options, but they were largely ignored by the mainstream.

dragontamer3• 12 years ago

Cobol programmers were excited about Cobol2014 updates.

C++ will continue to be used, much like Cobol has continued to be used for an eternity.

kyberias2• 12 years ago

Is that a fair comparison, though? Do we really see people writing significant new software using Cobol as we see using C++? We don't. Right now we're all probably running a lot of software written in C++ (hello, browser!) but none in Cobol.

kyberias2• 12 years ago

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

repsilat• 12 years ago

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

pjmlp10• 12 years ago

What is your point?

The point is that many of us, go to C++ because it is one of the few languages with ahead-of-time compilers available across multiple systems.

Now that we are experiencing a going native wave in terms of compiler toolchains for other programming languages, that reason is slowly becoming less relevant.

So many might choose another language, instead of waiting a few more years for the support to appear.

And what is "C++ triad"?

gcc, clang and Visual C++.

HN posts about C and C++ tend to forget there are many more C and C++ compilers out there.

72deluxe• 12 years ago

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

ttt123• 12 years ago

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.

pbsd• 12 years ago

There is talk of defining a stable ABI within platforms [1]. I'm not particularly fond of the current proposal, but there seems to be interest. We'll have to see how it plays out.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n402...

golemotron• 12 years ago

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• 12 years ago

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• 12 years ago

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

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.

coliveira2• 12 years ago

Turbo Pascal used a similar scheme, but they split every source file into an "interface" and an "implementation" section. The interface would end up as information exported to other modules, but in binary form. No other part of the process had to read the original source file.

_pmf_• 12 years ago

It's similar in Ada.

pjmlp10• 12 years ago

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.

acqq• 12 years ago

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?

maxlybbert• 12 years ago

I won't say that's been solved, but extern template is supposed to address it (well, exporting templates was supposed to address it, but that never really got off the ground).

Borland came up with an approach that instantiated templates multiple times, and then weeded out duplicates. That was relatively easy to implement, so everyone else followed suit. Extern template makes it possible to make sure some instantiations are instantiated only once, so the compiler doesn't have to weed out extra instantiations (I wish I could use "instantiate" fewer times in that description, but I can't see how to pull that off).

mattnewport• 12 years ago

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.

lomnakkus2• 12 years ago

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 includers to includees, so headers become independent of each other.

haberman• 12 years ago

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

pjmlp10• 12 years ago

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.

haridas• 12 years ago

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

aldanor• 12 years ago

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

A Module System for C++ (Revision 2) [pdf]

Related Stories