Re: Interest for C++20 modules support of boost officially

From: Chuanqi Xu (chuanqi.xcq_at_[hidden])
Date: 2024-12-23 03:19:59

> I'd like to understand more about this, since this is the approach I
have been following (and AFAIK, the one that John Maddock and Matt
Borland followed, too). What would be the possible ODR violations
here? Does he refer to the case where we forget to #ifdef-out an
include for a dependency?
The ODR violation is a misunderstanding or a miscommunication. The ODR violation can go away if it was wrapped by `extern “C++”`. 
> Does he refer to the case where we forget to #ifdef-out an
include for a dependency?
And yes, it seems like they mislooked this. I talked this privately with Mathias. (He mentioned this first in that mailing list). We can achieve the most ideal performance by #ifdef-out all the third party headers as the we do now.
> It looks like `export import <boost/foo.hpp>;` could be done easily by
users (if it worked).
Paste some reply from EWG’s mailing list:
The key point for the efficiency of modules is, we should avoid redeclarations in different BMIs. For example, for,
```
import <string>;
import <vector>;
...
```
For a naive support, that may compiles `string` to `string.pcm` and compiles `vector` to `vector.pcm` and load these 2 pcms to the current TU. This is not efficient enough. Since `string.pcm` and `vector.pcm` may contain duplicated redeclarations in common included headers. e.g., declarations in allocators. To avoid this, the tools must be able to replace the inclusion of every importable header to the import of the corresponding header units. So that `string.pcm` and `vector.pcm` can share the declarations in `allocator.pcm`. In another word, when tools see `import <header.h>`, the tools need to convert **every** indirectly included headers to header units to achieve the best efficiency.
So the conclusion is, for header units to work efficiently enough, the tools must be able to replace every (importable) textual inclusion to import for header units if possible. But the tools are far away from that state. CMake even doesn’t support the most trivial case. And other build systems which claim supporting header units may only support the trivial case too. My personal opinion is, to not care about it until the tools support it.
And the reason why I suggest #ifdef-out is, it actually did the above process to avoid redeclarations manually. And its refactoring costs and maintaining costs is low. So I feel the current method is fine and workable.
> https://github.com/anarthal/boost-cmake/tree/feature/cxx20-modules <https://github.com/anarthal/boost-cmake/tree/feature/cxx20-modules >
> https://github.com/anarthal/config/tree/feature/cxx20-modules <https://github.com/anarthal/config/tree/feature/cxx20-modules >
> https://github.com/anarthal/assert/tree/feature/cxx20-modules <https://github.com/anarthal/assert/tree/feature/cxx20-modules >
> https://github.com/anarthal/throw_exception/tree/feature/cxx20-modules <https://github.com/anarthal/throw_exception/tree/feature/cxx20-modules >
> https://github.com/anarthal/mp11/tree/feature/cxx20-modules <https://github.com/anarthal/mp11/tree/feature/cxx20-modules >
> https://github.com/anarthal/core/tree/feature/cxx20-modules <https://github.com/anarthal/core/tree/feature/cxx20-modules >
Quick action! And some of my suggestion is:
1. Use `.cppm` or even `.ixx` for the module interface units. Although build systems don’t force it, the suffix makes much easier to read by human beings. e.g., we can perform simple search for the use of modules by searching `*.cppm` in search engines.
2. Wrap the inclusion of headers in the module purview with `extern “C++”`. https://github.com/anarthal/throw_exception/blob/d32c0f3961934d15bbb938bb39d01bfce2653266/modules/throw_exception.cxx#L9 <https://github.com/anarthal/throw_exception/blob/d32c0f3961934d15bbb938bb39d01bfce2653266/modules/throw_exception.cxx#L9 >
3. Don’t import in headers: https://github.com/anarthal/throw_exception/blob/d32c0f3961934d15bbb938bb39d01bfce2653266/include/boost/throw_exception.hpp#L23-L24 <https://github.com/anarthal/throw_exception/blob/d32c0f3961934d15bbb938bb39d01bfce2653266/include/boost/throw_exception.hpp#L23-L24 > but import them in module interface.
Thanks,
Chuanqi
------------------------------------------------------------------
From:Ruben Perez via Boost <boost_at_[hidden]>
Send Time:2024 Dec. 22 (Sun.) 23:30
To:Peter Dimov<pdimov_at_[hidden]>
Cc:Ruben Perez<rubenperez038_at_[hidden]>; boost<boost_at_[hidden]>
Subject:Re: [boost] Interest for C++20 modules support of boost officially
> I was going to say that the same applies to the -std level, but it occurs to me
> that in order to build and use modules, you need at least -std=c++20 anyway
> so most such issues won't manifest for now, until we get conditional uses
> of C++23 or C++26.
In the prototype I'm writing, it's C++23, since everything uses import
std. As you have mentioned many times, that's the only way to cut
build times.
>
> We also have an interesting problem with -fno-exceptions; the function
> boost::throw_exception in that case is only declared on our side, but defined
> by the user. This (I think) means that the declaration can't be exported by the
> module, it needs to appear in the GMF. Maybe.
I haven't reached this yet, but my idea was to declare the function as
extern "C++", which AFAIK attaches it to the global module, even if
it's declared outside of it.
>
> By the way, I posted about the optional `export` idea to the committee mailing
> list, and Michael Spencer replied and basically said "don't".
>
> "My suggestion is to do either `export import <boost/foo.hpp>;` in the module
> if you are ok with getting extra declarations, or `export using ...` like libc++ does.
> Trying to textually include a header into the purview of a named module is
> fraught with issues."
>
> Since everything that's textually included becomes attached to the named
> module, it's too easy to create ODR violations.
>
> But, apparently, Clang doesn't like header units, so the above is also not quite
> optimal.
I'd like to understand more about this, since this is the approach I
have been following (and AFAIK, the one that John Maddock and Matt
Borland followed, too). What would be the possible ODR violations
here? Does he refer to the case where we forget to #ifdef-out an
include for a dependency?
It looks like `export import <boost/foo.hpp>;` could be done easily by
users (if it worked).
At the minute, `export using` has problems:
1) It doesn't work properly under MSVC because of an apparent language
bug regarding specializations [2] [3].
2) It ends up placing *a lot* of declarations in the global module
fragment. clang docs suggest to avoid this [1], and I recall someone
on the ML argued in this direction, too, but I can't find the relevant
message.
This is what I currently have. It's incomplete and will get some more
work today:
https://github.com/anarthal/boost-cmake/tree/feature/cxx20-modules <https://github.com/anarthal/boost-cmake/tree/feature/cxx20-modules >
https://github.com/anarthal/config/tree/feature/cxx20-modules <https://github.com/anarthal/config/tree/feature/cxx20-modules >
https://github.com/anarthal/assert/tree/feature/cxx20-modules <https://github.com/anarthal/assert/tree/feature/cxx20-modules >
https://github.com/anarthal/throw_exception/tree/feature/cxx20-modules <https://github.com/anarthal/throw_exception/tree/feature/cxx20-modules >
https://github.com/anarthal/mp11/tree/feature/cxx20-modules <https://github.com/anarthal/mp11/tree/feature/cxx20-modules >
https://github.com/anarthal/core/tree/feature/cxx20-modules <https://github.com/anarthal/core/tree/feature/cxx20-modules >
Thanks,
Ruben.
>
>
[1] https://clang.llvm.org/docs/StandardCPlusPlusModules.html#reduce-duplications <https://clang.llvm.org/docs/StandardCPlusPlusModules.html#reduce-duplications >
[2] https://anarthal.github.io/cppblog/modules2#template-spec <https://anarthal.github.io/cppblog/modules2#template-spec >
[3] https://github.com/anarthal/cppblog/issues/1 <https://github.com/anarthal/cppblog/issues/1 >
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost <http://lists.boost.org/mailman/listinfo.cgi/boost >