Am 17.12.2024 um 16:29 schrieb Peter Dimov via Boost:
Chuanqi Xu wrote:
For authors of libraries, after boost introduce modules, you only need to do 2 extra things: - In headers, add a macro (assume its name as BOOST_MODULE_EXPORT, which will be ‘export’ conditionally) to the entities that need to be exported. Would have been nice if the `export` keyword was accepted and silently ignored when outside of module.
Totally so! Whoever is considering to introduce module support into some Boost library should be acutely aware of, and familiar with, the following sections in the C++ standard and its implications: * http://eel.is/c++draft/module.reach#3 * http://eel.is/c++draft/module.reach in general and in particular * http://eel.is/c++draft/module.global.frag#3 * http://eel.is/c++draft/module.global.frag#4 This applies to all modules which are *not* leafs in the entire dependency tree and contain so-called global module fragments (http://eel.is/c++draft/module.global.frag) in user-facing TUs. Some compilers do *not* implement GMF entity pruning correctly, or at all. This will lead to disappointed and/or frustrated users, or - even worse - to users who are misled to assume seeing correct module BMIs, while these are - in fact - incorrect. This was one the topics in my modules workshop this fall (hint: stay away from Clang at least up to 18. Clang 19 *might* have improved in this regard). The recommended remedy is to avoid #includes of standard library headers at all and turn to import std; instead. But this is just the starting point. Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5