C++ Logo


Advanced search

Re: Header units again.

From: Gabriel Dos Reis <gdr_at_[hidden]>
Date: Thu, 13 Oct 2022 18:06:12 +0000
  * A header is importable if it isn't affected by the state of the preprocessor

What does that mean, concretely? I am asking because I cannot make sense of it, so I need help.

  * I think we would find that the vast, vast majority of headers are importable,

Who is “we” in that sentence and where are “we” looking?

-- Gaby

From: Corentin Jabot <corentinjabot_at_[hidden]>
Sent: Thursday, October 13, 2022 10:52 AM
To: sg15_at_lists.isocpp.org
Cc: Gabriel Dos Reis <gdr_at_[hidden]>; Iain Sandoe <iain_at_[hidden]>
Subject: Re: [SG15] Header units again.

You don't often get email from corentinjabot_at_[hidden]<mailto:corentinjabot_at_[hidden]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Is it though?

A header is importable if it isn't affected by the state of the preprocessor (or all headers in a project are designed to be used with the same preprocessor state).
I think we would find that the vast, vast majority of headers are importable, so the focus should be on those that are not.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1905r0.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2019%2Fp1905r0.pdf&data=05%7C01%7Cgdr%40microsoft.com%7C7b6c715f91e14c27514908daad43a888%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638012803726758131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=17YWz9w4HQB4HoL0YqyQFRePINv1Hi3Y510HZnRj3Gk%3D&reserved=0> proposed an in-source mechanism to do that (as i generally agree that source files should not overly rely on external information to be usable), but at the very least, build systems should provide an "all my headers are importable" option.

On Thu, Oct 13, 2022 at 11:45 AM Iain Sandoe via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
Hi Gaby, SG15,

I consider my question answered :)
.. and there is no point in pursuing this idea,


> On 13 Oct 2022, at 10:33, Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
> Really, "importable" is a description of *use* rather than an intrinsic state. Even a messy header file can turn can "be importable" with the right set of macro defines, etc.
> For all useful purposes, all the compiler has to do is accept producing a BMI when asked, and then document the conditions under which production and imports of such things work. A crude practical documentation that an implementation can offer is "If I can produce a BMI and the import works, then the header file is importable."
> Header units were invented as a way to speed up header file inclusion for existing headers that were written before modules were introduced in C++. Implicit in that assumption is that we can't go back and ask people to modify those headers. So, requiring an in-source thing to mark them defeats the purpose.
> I would suggest that we focus on use, as opposed to trying to categorize intrinsic state. The proof of the pudding is in the eating... 😊

> -- Gaby
> From: SG15 <sg15-bounces_at_[hidden]<mailto:sg15-bounces_at_[hidden]>> on behalf of Iain Sandoe via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
> Sent: Thursday, October 13, 2022 1:41:27 AM
> To: SG15_at_[hidden]<mailto:SG15_at_[hidden]> <SG15_at_[hidden]<mailto:SG15_at_[hidden]>>
> Cc: Iain Sandoe <iain_at_sandoe.co.uk<mailto:iain_at_[hidden]>>
> Subject: [SG15] Header units again.
> Hello SG15,
> Sadly the Friday meeting time is not one I can make usually, so email for now…
> ---
> Once again in the course of implementation work we find ourselves noticing that Header Units are special.
> * The compiler cannot determine from the source that a header is an importable one.
> * AFAICT, the build system can figure that a source depends on a specific header, but it is also not able to determine if that header is an “importable” one (except for the sub-set that are pre-defined to be). Which means that we probably require that the user’s project defines which headers are importable. That disconnects metadata from the sources which is undesirable, if not a recipe for bugs.
> I expect that this has been discussed before, and I’ve missed it somehow .. but several times during my implementation work on clang, it seemed to me that this problem would go away if importable header units were required to start with a keyword.
> The first idea that occurred would be to have them start with “module;” which matches the logical behaviour (the entire content is in the GMF). However, since we already have compiler diagnostics about ‘module;’ without a following ‘module XXX;’ that would presumably not work easily now.
> Suppose we chose to require that they start with “header-unit;”?
> it is
> * simple,
> * unlikely to clash with any other keyword intent
> * not an invasive source change
> * fast to parse for build systems and compilers alike.
> Given an expectation that the user has to identify importable header units somehow, doing it in the source seems to me to be the neatest solution.
> what did I miss?
> Iain
> P.S I was considering making this an NB comment - but feedback would be welcome.
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]<mailto:SG15_at_[hidden]>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&amp;data=05%7C01%7Cgdr%40microsoft.com%7C71442da7a0484e8c0c0c08daacf6bb26%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638012472965810801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=8P9fGRw3t2YfqHEADyEyYn0lcYvWzovuuxW26Pj3f9w%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C7b6c715f91e14c27514908daad43a888%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638012803726758131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=c8OJYUA7zGcZgYWUH6jrlVrVXu%2FdhSRHkEr3GIa8UAs%3D&reserved=0>

SG15 mailing list

Received on 2022-10-13 18:06:15