Date: Thu, 5 Dec 2024 19:46:39 +0100
On Wed, Dec 04, 2024 at 16:30:02 +0800, Chuanqi Xu via SG15 wrote:
> And maybe we design some syntax or interfaces to the library authors
> to let them say: this module is a wrapper for **these headers** and
> please emit header guard and `#pragma once` state for these headers. I
> believe this can speedup the process of modularization significantly.
This is somewhat related to this paper that Gaby presented:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p3041r0.pdf
What came to mind for me (using CMake terms to describe them) was for a
target providing importable headers to be able to state "if you see
this header import, provide this named module BMI instead". There's a
thread on this, but one "detail" is that there would need to be some
kind of macro-injection to insert the macros provided by that header
post-import. Now scanning doesn't care about this because it can just
read the header and get macros from it directly, but the collation
mechanism can then say "yeah, I see your header unit import, here's the
BMI for a named module instead".
I could forsee this working, though I'm sure there are implementation
details to work out (e.g., perhaps something to add to P1689 to give
"here's a macro-only header to inject when importing this module as
header X").
--Ben
> And maybe we design some syntax or interfaces to the library authors
> to let them say: this module is a wrapper for **these headers** and
> please emit header guard and `#pragma once` state for these headers. I
> believe this can speedup the process of modularization significantly.
This is somewhat related to this paper that Gaby presented:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p3041r0.pdf
What came to mind for me (using CMake terms to describe them) was for a
target providing importable headers to be able to state "if you see
this header import, provide this named module BMI instead". There's a
thread on this, but one "detail" is that there would need to be some
kind of macro-injection to insert the macros provided by that header
post-import. Now scanning doesn't care about this because it can just
read the header and get macros from it directly, but the collation
mechanism can then say "yeah, I see your header unit import, here's the
BMI for a named module instead".
I could forsee this working, though I'm sure there are implementation
details to work out (e.g., perhaps something to add to P1689 to give
"here's a macro-only header to inject when importing this module as
header X").
--Ben
Received on 2024-12-05 18:46:46