Em sex., 10 de jun. de 2022 às 10:20, Ben Boeckel
<ben.boeckel_at_[hidden]> escreveu:
> I'm of the opinion that this is analogous to "every TU using a header
> needs to see a coherent set of declarations" that is already in effect.
> Headers configured by defines (Boost PP, C and system headers with their
> `_GNU_SOURCE` and friends, etc.) are just not importable IMO.

Yes, I'm in the process of writing a paper to create a coherent mental
model of how header units work, and I have actually arrived at a
workable definition for "importable headers":

An importable header is a header where the state of the preprocessor
at the point of inclusion is not meant to semantically change how the
header should be translated, and where isolation from that state is
desirable.

> The alternative

Note that the compiler is allowed to replace `#include` by `import` on
any header it knows to be importable, which would mean it would be
fine for the compiler *not* to perform the alternative translations of
the headers. So a compiler would be able to make the translation up to
phase 4 only once for each importable header, and then reuse the
results.

But, you're right, if two different header units include the same
non-importable header, the compiler will need to perform the
translation up to phase 4 of that header for each importable header
that includes it. Hopefully there's enough room for optimization there
so it doesn't need to start from scratch every time.

Even with that cost, I think the benefits of the coherency of having
importable headers always seeing a coherent set of declarations is
more relevant. We have an opportunity to significantly reduce
accidental ODR violations created by different translation units
having different include directories and definitions in their command
lines, I think we should take it.

daniel