* I think it was you who some time ago was pointing out to me that implementations are allowed to do "things" related to the specification document that mundane users are not. My interpretation is that an implementation can define the macros specified in the standard through invisible #include <standard-header> -> 'std' redirection just the same as long as the respective #include <standard-header> is present in the source. Or does the "as-if" rule not apply here?

I believe it is even simpler than that: an implementation that uses scanning phase as part of its build can determine that the translation unit it is compiling – and even an entire “project” – does not use any of these feature test macros in any way that effect the modes it is invoked in, for example by using the dependency analysis I shared a few weeks ago, and proceed with the replacement.

-- Gaby

From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Daniela Engert via SG15
Sent: Friday, June 3, 2022 10:59 PM
To: sg15_at_[hidden]socpp.org
Cc: dani <dani_at_[hidden]>
Subject: Re: [SG15] "logical name" of importable headers

Am 03.06.2022 um 23:39 schrieb Gabriel Dos Reis via SG15:

You just reminded me why I discouraged WG21 from going with the future test macros train 😊



I will repeat what I said back then, if you're compiling with a certain standard language version set, you should just accept that the feature is available instead of playing #ifdefry games with feature test macros. They have their own ways of backfiring.

I think it was you who some time ago was pointing out to me that implementations are allowed to do "things" related to the specification document that mundane users are not. My interpretation is that an implementation can define the macros specified in the standard through invisible #include <standard-header> -> 'std' redirection just the same as long as the respective #include <standard-header> is present in the source. Or does the "as-if" rule not apply here?

The same is clearly no the case with headers (and macros) outside of the standard. But then, it's the library developer to provide a module manifest (just to give it a name) that lists the library include files that a redirection to a BMI can replace. If library developers choose to implement some of the library interface through macros then they still can by providing a header file that must obviously not be listed in the manifest. Users need to opt into such a redirection, sans macros of course, and figure out what this means to their own source code. Thinking even farther: the manifest could list that library header that's providing the macro definitions that are part of the library interface, and should implicitly be read during redirection.

I think such a mechanism would actually improve compatibility between the #include "lib/header" world and the import lib world because there's only one ground truth of all definitions: the BMI, compiled once and for all.

Just my thoughts worth of 0.0184 € given current inflation rates.

Ciao
  Dani



-- Gaby



-----Original Message-----

From: Daniel Ruoso <daniel_at_[hidden]><mailto:daniel_at_[hidden]>

Sent: Friday, June 3, 2022 2:01 PM

To: Gabriel Dos Reis <gdr_at_[hidden]><mailto:gdr_at_[hidden]>

Cc: sg15_at_[hidden]<mailto:sg15_at_[hidden]>

Subject: Re: [SG15] "logical name" of importable headers



Em sex., 3 de jun. de 2022 às 16:48, Gabriel Dos Reis

<gdr_at_[hidden]><mailto:gdr_at_[hidden]> escreveu:

Do you see silent semantics change, or a loud compilation break?

Any example?



One example is the version macros for specific things, such as

#define __cpp_lib_scoped_lock 201703

in the mutex header on libstdc++.



If that macro is no longer in scope after the code says #include

<mutex>, it could silently change behavior if anyone has an #if on

that macro.



daniel

_______________________________________________

SG15 mailing list

SG15_at_[hidden]<mailto:SG15_at_[hidden]>

https://lists.isocpp.org/mailman/listinfo.cgi/sg15<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7Cde32ccf770724db4267e08da45ef5ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637899191606840229%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y6EJE1%2B%2B%2FIM%2BfG7cePKaCgGIM239amXidMyjPmw9ARE%3D&reserved=0>


--
PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5