|
Boost : |
From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2024-12-22 15:30:11
> 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/config/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/mp11/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
[2] https://anarthal.github.io/cppblog/modules2#template-spec
[3] https://github.com/anarthal/cppblog/issues/1
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk