Source
tongari95•

  • I'm afraid I didn't see any mention of template, it'll be pointless if template cannot be exported.

  • Can a module be split into multiple files? e.g. ModuleA = a.ifc + b.ifc + ...

1
btapi•

Check this out: Modules proposal rev 3

4.10.1 Definitions

Definitions for templates listed in a module interface are subject to constraints similar to those for inline functions. Furthermore, a class template that is only declared (but not defined) in an export declaration is seen as an incomplete class template by importing translation units.

1
brand_x•

There is much to like in that proposal. One dangling thread (or possibly a failure in my understanding) is the following:

4.13.3 Both Use Each Other at the Interface Level This situation is much rarer; the interfaces of M1 and M2 should be considered log- ically as part of a single larger module and treated as such, even though it is con- venient from the programmer’s perspective to physically split the entities in two distinct source files. Nevertheless, it is possible for the programmer to set up a (delicate) processing order for the compiler to translate the interface parts of both modules, and then consume them independently.

As much as I hate circular dependencies in interfaces and strive to eliminate them, there are sometimes cases that are difficult to avoid. Consider a string module and a locale module, for example...

Traditionally, the solution to this has involved tolerating the presence of incomplete types in the signatures of functions, and in opaque pointers, provided those parts of an included header are not invoked. I'm not clear on how this will be addressed in the linked proposal.

1
one-oh•

There isn't anything to export for a template though, right? That would require a template instantiation, which would then be exportable; e.g., std::string.

From what I read, a module can be composed of several translation units:

A module declaration identifies, in the source file, the module to which a given translation unit belongs.

0
gnzlbg•

A fully constrained template should be exportable tho, since at declaration site the compiler can verify that the template function is valid for all types that fulfill the predicate (otherwise it is underconstrained) and thus it can be "precompiled" (to some intermediate representation).

At a call site the compiler just needs to check that the parameter types satisfy the template constraints. In which case template instantiation cannot fail so nothing else needs to be checked.

It is however unclear to me if this can provide a speed up at all (checking a template's body once instead of multiple times). However, even if this would provide a speed-up, constrained templates do not need to be properly (fully) constrained, so most templates won't be candidates for this anyways.

1
doom_Oo7•

It is however unclear to me if this can provide a speed up at all (checking a template's body once instead of multiple times). However, even if this would provide a speed-up, constrained templates do not need to be properly (fully) constrained, so most templates won't be candidates for this anyways.

Honestly, the biggest speed-up is not loading and reading each header file 500 times on a full rebuild of a project. In most projects I'd argue that template instantiation time is negligible versus the time spent in the preprocessor - this can be seen quite easily when setting up unity builds.

1
gnzlbg•

I'm not that sure. I now use cmake in all my projects to automatically create a cpp file for each header file to check that all headers include all the headers they need (check e.g. Boost.Hana's test/CMakeLists.txt tests.headers target for how to do this automatically).

This results in a lot of TUs that are compiled, some of them include almost the whole library. Still, all of them compile almost instantaneously, independently of the amount of headers they include. Boost.Hana is a header only template library so all its code is actually in the headers.

The moment one instantiates a single template, however, the world freezes, and compilation times explode from 2 seconds to 20-30 seconds (with clang) :/

So in my experience, while I agree that rereading each header a million times is wasteful, I think that re-instantiating all templates for each TU is even more wasteful. Compilers should have a cross-TU data-base of instantiated templates and reuse them.

Anyhow, there is a Rust talk where Chandler Carruth (Google/LLVM) says that clang spends on type-checking about ~0% of its running time.

2
one-oh•

True. I didn't quite think that through.

1
playmer•

So wait, can we actually test this implementation in VC++ 2015 right now? Will we be able to when Update 1 comes out?

0
mjklaim•

It says "Starting with Update 1 of its 2015 release, Visual C++ features an ongoing implementation of the module proposal presented in [1]."

VS2015 Update 1 is not released yet. It should be released very soon if I understood correctly.

1
playmer•

My confusion was the distinction between Vs 2014 Dev Update 1 and the section you noted.

Sorry, should've been more clear!

1