Date: Wed, 4 Dec 2024 08:29:11 +0100
On Tue, Dec 03, 2024 at 10:26:13 -0500, Jason Merrill via SG15 wrote:
> Just as the compiler is permitted to translate #include to import (
> https://eel.is/c++draft/cpp.include#7), -include can also import a header
> unit and avoid repeated preprocessing just like PCH.
>
> If you want macros, you want a header, whether included or imported as a
> header unit; as Daniela says, a small header that imports a module is worth
> considering.
>
> I've been considering a built-in macro like __has_include for imports, so
> that a header can choose to skip non-macros if its contents are available
> from a module. My initial thought was to ask if 'import foo' would
> succeed, but that seems too dependent on the state of the build, so now
> lean more toward asking whether 'import foo' has already happened.
Right, `__has_import` makes it impossible to build (reliably). The issue
is that the answer depends on the order of the build and in order to get
the order of the build, we need to know the imports, so if it exists, it
can only matter within the module purview, but then you can just look at
the top of the file to see if the name you're asking about has an
`import` line for it or not (or reuse the same preprocessor condition
guarding the `import` and if that is complicated, do a `#define
decided_to_import_foo 1`). I don't see a (workable) use case for such a
thing.
--Ben
> Just as the compiler is permitted to translate #include to import (
> https://eel.is/c++draft/cpp.include#7), -include can also import a header
> unit and avoid repeated preprocessing just like PCH.
>
> If you want macros, you want a header, whether included or imported as a
> header unit; as Daniela says, a small header that imports a module is worth
> considering.
>
> I've been considering a built-in macro like __has_include for imports, so
> that a header can choose to skip non-macros if its contents are available
> from a module. My initial thought was to ask if 'import foo' would
> succeed, but that seems too dependent on the state of the build, so now
> lean more toward asking whether 'import foo' has already happened.
Right, `__has_import` makes it impossible to build (reliably). The issue
is that the answer depends on the order of the build and in order to get
the order of the build, we need to know the imports, so if it exists, it
can only matter within the module purview, but then you can just look at
the top of the file to see if the name you're asking about has an
`import` line for it or not (or reuse the same preprocessor condition
guarding the `import` and if that is complicated, do a `#define
decided_to_import_foo 1`). I don't see a (workable) use case for such a
thing.
--Ben
Received on 2024-12-04 07:29:19