(Hi, author of the article)

The issue is, "how do you find these dependent modules?". As of right now, there is no way to find a module. It is not tied to a location in a subdirectory, nor is the name of a module tied to the file itself. I'm fine if we can get the dependency information, but how can we do that if there is no guarantee for finding the actual dependencies? Leaving these decisions unspecified by the C++ standard is dangerous. Having an important thing such as "how does the name of a module map to the name of the translation unit it contains?" be none of "undefined", "ill-formed", or "implementation defined" is asking for trouble. And to be quite honest, I don't see how running the compiler in a minimal parsing mode (once for each module), followed by running the compiler a second time for its full IFC (or whatever file format is used) and possible object file generation can be a good idea.

Running the compiler twice (first in preprocessor mode), then in actual compilation mode is exactly what is done now for many build systems. The first pass, in addition to building dependencies also generates the mapping from files to modules. You will need to list all the files you need to 'preprocess' in your build script, to generate the dependencies, but that's what it is done today already and I don't see a way out nor even a need to change. Modules are not supposed to enforce a specific build strategy, nor they should.

The standard currently imposes very little requirements on the actual build process, headers and source files do not even need to exist as actual files on a system, so it would be a lot of work to actually introduce these concepts in the standard and risk delaying modules further.

That doesn't mean that there might not valuable to standardize that, but it is another battle and many (I, for example) will argue that a strict mapping from file names to module names is wrong.

Forgive me, but I can't think of a single build system where the compiler is run on a source file twice. All of the ones I've seen support either parsing the .d file generated by a compiler, or parse /showIncludes if using MSVC. If you have any examples of build systems doing this, I'd love to see them so I can avoid them.

I've seen at least one, but it's proprietary and internal to my bigco. I'm willing to bet there's quite a few more at other bigcos. So lucky for you if you can avoid them, but I'm pretty sure there's many of us who don't get that choice.

> The build system can then collet all these dep files and reconstruct the full dependency graph.

And you actually want some tools to do a version of this. In particular, IDEs and smarter text editors. And, at scale, maybe even automated build systems. Though all these (not compilers and not build scripts) tools will likely want to do things incrementally, if it's possible and beneficial enough.

This reminds me a little bit of the C++ compilers (HP's?) that would build a database of instantiated STL types to avoid rebuilding std::basic_string<char> for every translation unit.

In fact, starting with C++11, you can do this in your projects. Make a common header file with contents like this:

    extern template class std::basic_string<char>;
    extern template class std::vector<int>;
    // etc...

and a corresponding .cc file like this:

    template class std::basic_string<char>;
    template class std::vector<int>;
    // etc...

The template instantiations you list will be compiled in that .cc's object file. Anyone who includes the header will assume those templates were instantiated elsewhere. Net effect is the listed templates are only compiled once.

(Of course this doesn't alleviate the problem of parsing the template header files over and over.)

See the section on explicit instantiation here: http://en.cppreference.com/w/cpp/language/class_template

Now I'm wondering what is a good way to measure my project's top 100 redundantly instantiated templates.

  find build/ -name \*.o -exec nm -C \{} \; | egrep ' W .*<' | sort | uniq -c | sort -n

is what I use. This lists all templated, implicitly instantiated, non-inlined symbols in increasing order of number of uses. Note that templates internal to libstdc++ will also show up and you may want to instantiate these too.

Note that explicit instantiation won't decrease the size of your object files, only the compilation time. (By default, the linker throws away duplicate instantiations.)

gcc has -ftime-report which is kinda opaque but still interesting.

Doesn't this prevent a lot of inlining? Or perhaps the compiler is smart enough in most cases?

No change to inlining. The definitions are still in the headers and the compiler will still eagerly inline them if they are defined in the class declaration (as typical) or defined outside the class declaration and explicitly marked inline (less typical).

(Whether inlining of non-trivial methods is desirable is - and in fact recently was - a discussion for another HN story.)