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

From: Daniela Engert (dani_at_[hidden])
Date: 2024-08-07 15:09:27

Am 07.08.2024 um 11:29 schrieb Boris Kolpackov:
> Daniela Engert via Boost<boost_at_[hidden]> 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-modules). 
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