Re: On Boost and modules

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-04-08 21:09:45

On 4/8/24 22:04, Stephan T. Lavavej wrote:
> [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.

Why changing compiler options affects C++ AST? Which is what the
compiled module basically is, or supposed to be, anyway.

Yes, the AST could change because of different macro definitions, but
that is not an issue. Or not more of an issue than it currently is with
different macro definitions between TUs. I don't expect modules to solve
this issue.

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

Maybe, but one needs to build it first in its entirety. And there are
cases when you *always* build from scratch. For example, in CI. This
seems like a deal breaker to me.

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

Again, why this is needed? As far as I'm concerned, the standard library
is bundled with the compiler, and its module should ship with it, just
like headers and compiled library currently are.

>> 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++"​.

Could you give an example? Does this involve some compiler-specific
magic (i.e. non-portable), beyond marking symbols exported from the
compiled library with
__declspec(dllexport)/__attribute__((visibility("default")))?

> (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.)

Is the order of includes and imports a fundamental limitation or is this
a limitation of current implementations that will be lifted in the future?