Date: Thu, 18 May 2023 16:37:26 -0400
Em qui., 18 de mai. de 2023 às 15:19, Tom Honermann
<tom_at_[hidden]> escreveu:
> I agree with your interpretation of the standard. Since the standard is not concerned with build systems, implementation-defined was pretty much the only option for specifying which header files are importable (without introducing additional syntax).
Yes. The specification does not make any attempt to define what makes
a header importable or not.
My understanding is that the intention was to model Explicit Clang
Header modules, where the build system tells the compiler what the
header units are, and early reports of adoption in the MSVC world
seems to suggest my understanding is correct.
There is no specification on the relationship with the preprocessor
state, particularly because there is a desire that the optimization is
not required to create a BMI for every possible state at the time of
the import, since that would result in almost no reuse, but at the
same time it's difficult to specify that behavior without using a lot
of build-system-specific words.
> On 5/17/23 2:16 AM, 许传奇(夜灯) wrote:
> But the consequence is that the C++ ecosystem is going to a more breaking state. For example, MSVC (or MSBuild?)
> introduces header-units.json (https://learn.microsoft.com/en-us/cpp/build/reference/header-unit-json-reference?view=msvc-170).
> And GCC has module map for named modules (I am not sure about gcc's state for header units). Clang has non-standard clang module
> maps and doesn't have a solution for header units. It looks like things are not going right.
I just posted P2898R0 so we can discuss in Varna on this whole
situation. I think Importable Headers as a specification is not
necessary to achieve the original goals of introducing Importable
Headers, and instead we could probably achieve all the goals just
saying the implementation can optimize source inclusions in different
ways than just pasting the entire content, with implementation-defined
caveats regarding the preprocessor state. The important bit being that
the semantics of "souce inclusion" are still the "canonical" behavior,
but the implementation is allowed to introduce optimizations with
implementation-defined caveats where appropriate.
I was writing an email with a new thread to discuss P2989R0 when I saw
this, I'll still start a new thread for that to make sure people are
aware, but I think Importable Headers is not Universally
Implementable.
daniel
<tom_at_[hidden]> escreveu:
> I agree with your interpretation of the standard. Since the standard is not concerned with build systems, implementation-defined was pretty much the only option for specifying which header files are importable (without introducing additional syntax).
Yes. The specification does not make any attempt to define what makes
a header importable or not.
My understanding is that the intention was to model Explicit Clang
Header modules, where the build system tells the compiler what the
header units are, and early reports of adoption in the MSVC world
seems to suggest my understanding is correct.
There is no specification on the relationship with the preprocessor
state, particularly because there is a desire that the optimization is
not required to create a BMI for every possible state at the time of
the import, since that would result in almost no reuse, but at the
same time it's difficult to specify that behavior without using a lot
of build-system-specific words.
> On 5/17/23 2:16 AM, 许传奇(夜灯) wrote:
> But the consequence is that the C++ ecosystem is going to a more breaking state. For example, MSVC (or MSBuild?)
> introduces header-units.json (https://learn.microsoft.com/en-us/cpp/build/reference/header-unit-json-reference?view=msvc-170).
> And GCC has module map for named modules (I am not sure about gcc's state for header units). Clang has non-standard clang module
> maps and doesn't have a solution for header units. It looks like things are not going right.
I just posted P2898R0 so we can discuss in Varna on this whole
situation. I think Importable Headers as a specification is not
necessary to achieve the original goals of introducing Importable
Headers, and instead we could probably achieve all the goals just
saying the implementation can optimize source inclusions in different
ways than just pasting the entire content, with implementation-defined
caveats regarding the preprocessor state. The important bit being that
the semantics of "souce inclusion" are still the "canonical" behavior,
but the implementation is allowed to introduce optimizations with
implementation-defined caveats where appropriate.
I was writing an email with a new thread to discuss P2989R0 when I saw
this, I'll still start a new thread for that to make sure people are
aware, but I think Importable Headers is not Universally
Implementable.
daniel
Received on 2023-05-18 20:37:39