Re: On Boost and modules

From: Stephan T. Lavavej (stl_at_[hidden])
Date: 2024-04-08 19:04:25

[Andrey Semashev]
> I find the fact that modules, including std, are not redistributable and
> that they must be built for every project extremely disappointing.

This allows modules to respect compiler options (including Standard modes) and macro definitions.

> Remember that we
> typically use only small portions of Boost, or even small portions of
> select Boost libraries. It doesn't make sense to have to build the whole
> Boost into a module only to pull a small part from it.

Quite the opposite - building Boost into a module makes subsequent imports lightning-fast, especially when only small portions are used (and must pay instantiation costs).

> This is also relevant to the standard library. Will we have to build the
> ever-growing std module every time we need a smallest thing from the
> standard library? This sounds like a disaster to me.

Again, quite the opposite. You need to build the Standard Library Modules when your compiler options change (of course you can keep separate directories for separate configurations). After that, the built modules can be used until your toolset version changes.

> One other thing that isn't clear is how modules interact with compiled
> libraries. I don't suppose modules will replace static/shared libraries,
> so I presume a module will be added on top of the library? How should it
> "export" the symbols that are already exported from the compiled library
> then?

If you want separately compiled source files to be usable with classic headers or named modules equally, this is possible. In MSVC we've achieved this for the Standard Library by using extern "C++"​. (We're still working on handling having both classic includes and named module imports within a single TU; that's the most challenging case. As of VS 2022 17.10, including an STL header before import std;​ works, but not the other way around.)

[Robert Ramey]
> It seems to always turn out that this is due to lazy
> programmers just including too much, ("convenience" headers)

Good news, then - modules make this essentially a non-issue. Importing a module and doing nothing with it is extremely cheap, because a module is a highly structured representation of library code which can be looked up on-demand. That's why we have a monolithic `import std;` that's near-instantaneous to drag in, compared to even a single "fine-grained" `#include <iostream>`.

> including the same thing over and over again (header only libraries)

This is partially mitigated by modules, since the cost of having to parse (and do the initial phase of lookups etc.) is paid once when building the module.

I say "partially" because instantiation costs are still paid per TU. Theoretically, this is one of the few scenarios where PCHes could theoretically have superior throughput to modules, since PCHes (compiler memory snapshots) can capture instantiations along the way. However, PCHes are so inflexible, that giving that up should generally be worthwhile.

STL