Ruben Perez via Boost
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