Re: On Boost and modules

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

On 4/9/24 00:09, Andrey Semashev wrote:
> 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.

Re. standard versions, there are ways to support multiple standard
versions and still ship the compiled std module. For example:

1. Ship everything in the same module std. This will make the module std
expose symbols defined by all C++ versions, but that should not be a
problem, as conforming user's code will use whatever matches his chosen
C++ version.
2. Ship multiple compiled modules for different C++ versions. Pick one
during compilation. Will also need to do this to support debug and
release versions of the standard library.

Maybe there are other ways, those two are just what immediately came to
mind.

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