Date: Tue, 3 Dec 2024 07:39:38 +0100 (CET)
> James via SG15 <sg15_at_[hidden]> hat am 03.12.2024 07:04 CET geschrieben:
>
>
> While working with C++ modules, I’ve noticed there’s currently no way to export macros from a module. Even if you wanted to opt into this, there’s no mechanism available.
This is not exactly correct: the mechanism to export macros from modules is called "header units".
> Given that macros are still essential for tasks like conditional compilation, this feels like a limitation. While macros can be controversial, they do help avoid repetitive and error-prone boilerplate in certain cases.
> Using headers is still an option, but it somewhat defeats the purpose of modules since each header needs to be parsed and preprocessed for every translation unit.
The "easy" way around such perceived limitations is wrapping the module into a tiny header which implicitly imports the module, and brings a set of macros with it.
> PCHs can help, but they’re limited to a single PCH per project and require additional setup.
> I’d like to see a solution to this, but I’m unsure of the best path forward. Here are a few ideas I’ve considered:
> 1-) Allow exporting macros from modules (perhaps with a special directive like "#define_export").
> 2-) Enhance PCHs to be importable from consumed libraries. (meaning consumers will have both their own PCH(if there is one) and also consumed libraries' PCH precompiled)
> 3-) Introduce a mechanism for exporting macros from modules that are preprocessed only once.
My experiences from working with modules for the past 6 years, and having them in production for nearly 3 years, never gave rise to advocate *language* changes similar to your ideas. But may be my use cases are just different.
Dani
>
>
> While working with C++ modules, I’ve noticed there’s currently no way to export macros from a module. Even if you wanted to opt into this, there’s no mechanism available.
This is not exactly correct: the mechanism to export macros from modules is called "header units".
> Given that macros are still essential for tasks like conditional compilation, this feels like a limitation. While macros can be controversial, they do help avoid repetitive and error-prone boilerplate in certain cases.
> Using headers is still an option, but it somewhat defeats the purpose of modules since each header needs to be parsed and preprocessed for every translation unit.
The "easy" way around such perceived limitations is wrapping the module into a tiny header which implicitly imports the module, and brings a set of macros with it.
> PCHs can help, but they’re limited to a single PCH per project and require additional setup.
> I’d like to see a solution to this, but I’m unsure of the best path forward. Here are a few ideas I’ve considered:
> 1-) Allow exporting macros from modules (perhaps with a special directive like "#define_export").
> 2-) Enhance PCHs to be importable from consumed libraries. (meaning consumers will have both their own PCH(if there is one) and also consumed libraries' PCH precompiled)
> 3-) Introduce a mechanism for exporting macros from modules that are preprocessed only once.
My experiences from working with modules for the past 6 years, and having them in production for nearly 3 years, never gave rise to advocate *language* changes similar to your ideas. But may be my use cases are just different.
Dani
Received on 2024-12-03 06:39:45