On 5/21/23 9:48 PM, 许传奇(夜灯) wrote:
> Hi Boris,
>
> > The standard is pretty clear that an imported header does not "see"
> any macros defined by the importer.
>
> This is surprising to me. Where is the corresponding wording? I just
> searched
> the context and didn't find the wording. And if it is true, it implies
> that the following
> transition is invalid, isn't it?
I think the most applicable wording is [module.import]p5
<http://eel.is/c++draft/module.import#5>. It defines how a header unit
is constructed and, since it doesn't specify that the state of the
preprocessor at the point of import is involved, that presumably means
that it isn't. A note that contrasts that behavior with source file
inclusion could be helpful.
>
> ```
> // foo.h
> #define FOO_H
>
> // bar.h
> #ifdef FOO_H
> ...
> #else
> ...
> #endif
>
> // user.orig.cpp
> #include "foo.h"
> #include "bar.h"
>
> // user.cpp
> import "foo.h";
> import "bar.h";
> ```
>
> Now we can't assume `user.cpp` isn't the same with `user.orig.cpp`. It
> is surprising since such patterns are
> pretty common in practice. And I'm worrying that we'll meet problems
> if this is true.
Yes, such patterns are fairly common. Headers that behave like bar.h
should not be nominated as importable (and would ideally be diagnosed by
implementations at import time as QoI). I don't know if we have wording
that addresses this.
> > I think these concerns should be addressed by SG15. An
> implementation dependent configuration file like you suggest is one
> way forward. Another would be for SG15 to specify a #pragma directive
> or magic comment (similar to the "-*- coding: <encoding name> -*-"
> comment that some editors recognize as an indication of source code
> character encoding; e.g. a "// importable-header" comment; I'm not
> suggesting this is a good idea).
>
> I remember Iain had a similar idea. But this was rejected due to the
> intention of header units is to adopt module-like things easily
> without a touch to the existing code. But such ideas break such
> assumption. So maybe we can't decide if a header is importable header
> by changing its source code.

I think it is possible to diagnose an attempted import of a
non-importable header algorithmically by recording in the BMI the macros
that would have contributed to different preprocessor translation if set
differently and comparing those to the macro state of the preprocessor
at import time. I don't know if it would be reasonable to require
implementations to do so though.

Tom.

>
> Thanks,
> Chuanqi
>
>
>
>
> ------------------------------------------------------------------
> From:Boris Kolpackov <boris_at_[hidden]>
> Send Time:2023 May 21 (Sun.) 16:56
> To:Tom Honermann via SG15 <sg15_at_[hidden]>
> Cc:Chuanqi <chuanqi.xcq_at_[hidden]>; Tom Honermann
> <tom_at_[hidden]>
> Subject:Re: [SG15] Questions about wording and design intention
> for header units and ideas
>
> Just one to point out that the assumption in the motivating example
> (that started this discussion) is incorrect:
>
> > On 5/17/23 2:16 AM, "许传奇(夜灯)" <chuanqi.xcq_at_[hidden]>
> wrote:
> >
> > > First, the motivation example:
> > >
> > > ```
> > > // a.cpp
> > > import "foo.h";
> > >
> > > // b.cpp
> > > #define M 43
> > > import "foo.h"
> > > ```
> > >
> > > The question is, for build systems, how can they know if they
> should
> > > use the same BMI for these 2 imports. Since **currently** the
> build
> > > systems don't have a **good** method to know whether a macro is
> > > interesting to a specific file.
>
> The standard is pretty clear that an imported header does not "see"
> any macros defined by the importer.
>
>