Date: Tue, 3 Dec 2024 09:14:34 +0100 (CET)
> James <james.business.84_at_[hidden]> hat am 03.12.2024 08:50 CET geschrieben:
>
>
> Can you give an example of "header units"? I can't find an example of that.
you might want to look at http://eel.is/c++draft/cpp.import or http://eel.is/c++draft/module#import-5
> If I understand correctly, you mean I can have a header unit "foo" which can be imported from "main.cpp" and "main.cpp" can access macros, right?
> ```cpp
> import foo;
> constexpr int val = SOME_MACRO_FROM_FOO;
> ```
Pretty close, you need to massage your import a bit
>
> On Tue, Dec 3, 2024 at 9:39 AM Daniela Engert <dani_at_[hidden]> wrote:
> >
> > > 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
> >
>
>
> Can you give an example of "header units"? I can't find an example of that.
you might want to look at http://eel.is/c++draft/cpp.import or http://eel.is/c++draft/module#import-5
> If I understand correctly, you mean I can have a header unit "foo" which can be imported from "main.cpp" and "main.cpp" can access macros, right?
> ```cpp
> import foo;
> constexpr int val = SOME_MACRO_FROM_FOO;
> ```
Pretty close, you need to massage your import a bit
>
> On Tue, Dec 3, 2024 at 9:39 AM Daniela Engert <dani_at_[hidden]> wrote:
> >
> > > 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
> >
Received on 2024-12-03 08:14:36