From: Daniela Engert (dani_at_[hidden])
Date: 2024-04-09 09:25:42
> Boris Kolpackov via Boost <boost_at_[hidden]> hat am 09.04.2024 08:57 CEST geschrieben:
>
>
> Ruben Perez via Boost <boost_at_[hidden]> writes:
>
> > AFAIK libc++ makes it work by making the std modules a proxy to the
> > standard headers, with the "export using" idiom.
>
> At least up to Clang 18 it "works" to the same level as in MSVC 17.10:
> include-before-import works, the other way around -- doesn't. It's
> possible this has changed in Clang 19, though.
>
Right, and this precludes any non-trivial use of 'import std' when you can't control *all* dependencies in their entirety. You need to guarantee that *all* #includes of header files lexically appear before all imports that directly or indirectly depend on those same header files. In *all* translation units.
The standard *mandates* implementers to make the interoperability of #includes of standard C++ headers and the modularized standard library happen, regardless of ordering (with different levels of compliance in current implementations). But there is no such guarantee for other libraries.
I see a lot of people that underestimate what it takes to get this right.
Experience level 1: look Ma, my module compiles! I know modules!
Experience level 2: look Ma, I can import my module into a .cpp file! I know modules!
Experience level 3: look Ma, I can import my module into another module and it works!
Experience level 4: look Ma, I can import my module and other modules that import my module into the same .cpp files!
Experience level 5: that whole stuff actually links and does what it it supposed to do. On one compiler.
Experience level 6: you can repeat that, on multiple compilers.
The demo application from last year's talks was deliberately constructed such that I could demonstrate what it takes to get there. The hardest part was to deal with Asio, clang, and all the ABI deficiencies that were unveiled along the journey.
Dani