Re: The Future of C++ and Boost - C++ Modules

From: Soronel Haetir (soronel.haetir_at_[hidden])
Date: 2022-05-13 20:43:31

What I've noticed with modules (trying with MSVC) is that they are
incredibly sensitive to compiler settings. I don't see MS (other
vendors too, for that matter) saying "these are the settings that will
be used, despite our tools offering much more". And I also have a
difficult time seeing modules losing that sensitivity, it would
basically require that the module contain the original
pre-preprocessed source. Or shipping an awkward - and growing - number
of module files.

For the time being I see modules as a nice idea that still needs lots
of work. Plus, there are things that can be done with includes that as
far as I'm aware modules simply don't support (Boost.Preprocessor's
iteration facility as an example).

On 5/13/22, John Maddock via Boost <boost_at_[hidden]> wrote:
>
>> If they ever are.
>>
>> Modules can work for leaf libraries, but for libraries used as
>> dependencies
>> by other libraries, you'll encounter a situation where the same
>> translation
>> unit imports boost.lib or "boost/lib.hpp" in one place and then includes
>> "boost/lib/something.hpp" in another, which is probably never going to
>> work correctly.
>>
>> I suppose it might stand a chance if all the imports are done first, so
>> that
>> the include guard macros are defined. But I think that's not going to work
>> in practice either.
>>
>> Basically, all Regex consumers also must respect the REGEX_AS_MODULE
>> macro and switch to `import boost.regex`. Repeat per every library.
>
> Modules don't expose macros, so there is no way to signal "this must be
> used as a module", so you have to find every usage of library X and make
> sure they are either all modules or all includes.  Or at least that
> anything included doesn't use import: the other way around is fine since
> the include is hidden within the module.
>
> John.
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Soronel Haetir
soronel.haetir_at_[hidden]