Re: [boost] [config] First steps towards C++20 modules

Am 07.08.2024 um 11:29 schrieb Boris Kolpackov:

Daniela Engert via Boost writes:

...

// module lib export module lib; #define BOOST_MODULE_EXPORT export #ifdef BOOST_xxx_ATTACHED_TO_GLOBAL_MODULE extern "C++" { #endif #include "internal.h" #ifdef BOOST_xxx_ATTACHED_TO_GLOBAL_MODULE } #endif Are you aware of any substantial codebases that successfully use this approach?

Does Microsoft's STL implementation count as "substantial"? BTW: do you know of *any* substantial non-STL codebase that uses modules in any meaningful way? Besides Microsoft Office, of course.

Specifically, this idea of having a header that implements both the header and module interfaces with the same source code and which is then included in the module purview wrapped in extern "C++"? We do in our company. We use a mixture of headers, pure modules (made from scratch), modules with headers wrapped by 'extern "C++"' like you mention, modules with headers exporting (parts) of their interface by exported using-declarations, and combinations of that, in the codebase driving a huge machine that is developed since 2021 and has precursors (i.e. builds from code) starting from 2007. 3rd-party libraries (usually modules wrapping headers) are part of that. This codebase is in the 1M LOC range. Feels like there bound to be gotchas.

Right: Clang is sometimes failing to merge definitions in the global module coming from both headers and modules. (documented here: https://clang.llvm.org/docs/StandardCPlusPlusModules.html#known-issues)

For example, that header likely includes other headers (is it ok to wrap a standard library headers in extern "C++"?)

It is, see  [std.modules] and in particular [std.modules]/4. Microsoft does. I did in my CppCon 2022 keynote and later when there were no working implementer-supplied modularized standard C++ library modules available yet (e.g. ms-stl and libstdc++).

and maybe even imports some modules (potentially without even knowing that, for instance, via a third-party header).

If you can't control that, you *need* to attach affected pieces of your code to the global module - with all its drawbacks like increased compile times. The biggest problem today in my opinion are alleged modules that are missing meaningful tests. By that I mean modules which don't dare to test their usability from the consumer perspective. Just a week ago, I gave the 'argparse' library a shot and reported by findings in this thread here: https://hachyderm.io/deck/@DanielaKEngert/112876206120670198. The code - in particular the tests - is here: https://github.com/DanielaE/argparse/tree/module It uses the 'extern "C++"' technique that I invented for the {fmt} library early 2021. Clang also (quite recently) documents it as one of two options to modularize existing libraries (see: https://clang.llvm.org/docs/StandardCPlusPlusModules.html#transitioning-to-m...). It is more powerful - but also more involved - than the 'export using' technique used by e.g. the modularized libc++ standard library.

BTW, we are in the process of considering what mechanisms we should have in build2 for mixing modules/headers packages and I wrote some thoughts on the possible approaches to implement such dual header/modules support, in case anyone is interested:

https://github.com/build2/build2/issues/413#issuecomment-2272932212

Thanks, Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5