Boris Kolpackov via Boost
hat am 09.04.2024 08:57 CEST geschrieben: Ruben Perez via Boost
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