Date: Sat, 4 Jun 2022 07:59:15 +0200
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]>
> Sent: Friday, June 3, 2022 2:01 PM
> To: Gabriel Dos Reis<gdr_at_[hidden]>
> Cc: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]> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/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]>
> Sent: Friday, June 3, 2022 2:01 PM
> To: Gabriel Dos Reis<gdr_at_[hidden]>
> Cc: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]> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
-- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
Received on 2022-06-04 05:59:16