Re: On Boost and modules: second part

From: Boris Kolpackov (boris_at_[hidden])
Date: 2024-04-19 11:40:39

Ruben Perez via Boost <boost_at_[hidden]> writes:

> From https://anarthal.github.io/cppblog/modules2:

> Under MSVC, mixing standard includes and imports is problematic. This
> is true even if the mix happens in different translation units, as
> long as they interact via import.

We have tried this with 17.10 preview4 and there is definitely an
improvement. Not only this works:

#include <iostream>
import std;

But also something like this (which is trying to test the above-
mentioned interaction via import):

// a.mxx
module;
#include <iostream>
export module a;
export void a (std::ostream& os) {os << "a";}

// b.mxx
export module b;
import std;
export void b (std::ostream& os) {os << "b";}

// c.mxx
export module c;
import a;
import b;
import std;
export void c (std::ostream& os) {a (os); b (os);}

// main.cxx
#include <iostream>
import c;
int main () {c (std::cout);}

This works for all the permutations of the import order in c.mxx.

Having said that, when we tried to enable `import std;` in a more
realistic project, things did fall apart pretty quickly due to
what looks like hard to pin-point interactions between include
and import.

> * Create a BOOST_XXX_MODULE_EXPORT macro, defined to export if we’re doing
>   modules, empty otherwise.
>
> * Annotate all public entities in our headers with the aforementioned macro.
>
> * Ifdef-out all third-party includes from our headers if we’re doing modules
>   (including standard library and other Boost library includes) - these will
>   be made available with import.

In the early modules days I tried this dual modules/headers approach on
a relatively small library. It didn't go well, to put it mildly. The
resulting headers/module interfaces got really hairy due to all the
macros and ifdef's.

One thing I found particularly dizzying (literally) is keeping straight
all the imports/includes in the module interface and implementation
units. Remember that when you do, for example,`import std;` in the
module interface in the module's purview, all the imported names are
automatically made visible in the module implementation units without
an explicit `import std;`. But that's not the case with headers and
you will need to pause and think where you need to include each header.

If you are interested to see what it used to look like, here is the
commit that ripped all this dual support out:

https://github.com/build2/libbutl/commit/df1ef68cd8e85