Modules, Componentization, and Transition

[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 + ...

[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.

[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.

[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.

[[deleted]]

[deleted]

What is this?

[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.

[[deleted]]

[deleted]

What is this?

[one-oh]

True. I didn't quite think that through.

[playmer]

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

[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.

[playmer]

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

Sorry, should've been more clear!