Date: Sun, 1 Nov 2020 16:36:16 +0000
> One of the SG10 guidelines is that feature test macros are generally only needed if the programmer would write the code in two different ways depending on the setting of the macro.
If the feature test macro is useful in a static_assert, I can see it being somewhat useful, but I don't know that that is currently an SG10 guideline.
Regardless, if someone wants a feature test macro, I would like to see example code that demonstrates such use. A 60 second attempt on my part to come up with a static_assert for this macro didn't yield anything that would be useful.
If re-ordering were permitted, then there could be a macro that is 0 when reordering is on, and something else when reordering is off, and not-present would be left non-portable. That's not the pitch though.
________________________________
From: SG10 <sg10-bounces_at_[hidden]> on behalf of John Spicer via SG10 <sg10_at_[hidden]>
Sent: Sunday, November 1, 2020 10:08 AM
To: Ville Voutilainen via SG10 <sg10_at_[hidden]>
Cc: John Spicer <jhs_at_[hidden]>
Subject: [EXTERNAL] Re: [SG10] P1847 Make declaration order layout mandated
Having a feature test macro for this seems to be of limited usability.
If the macro existed, EDG would probably use our configuration parameter (mentioned in the paper) to control the setting of the macro.
But a user of the macro would probably have to assume that the macro not existing (as would be the case for pre-C++23 compilers) means that the order is the one expected by the paper. So if some older compiler did not use the expected layout, the macro wouldn’t help.
One of the SG10 guidelines is that feature test macros are generally only needed if the programmer would write the code in two different ways depending on the setting of the macro.
So, it doesn’t seem that helpful to me, but I have no objection to adding a macro for this if there is sufficient interest in doing so.
John.
On Nov 1, 2020, at 10:25 AM, Barry Revzin via SG10 <sg10_at_[hidden]<mailto:sg10_at_[hidden]>> wrote:
Hi SG10,
On Thu, Oct 29, 2020 at 7:05 AM Balog Pal via SG10 <sg10_at_[hidden]<mailto:sg10_at_[hidden]>> wrote:
I asked guidance after the last meeting. I did not get a reply back then
and concluded it as confirming the idea to NOT have the macro.
If someone thinks it is needed after all, please say so.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p1847r3.pdf<https://urldefense.com/v3/__http://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p1847r3.pdf__;!!FbZ0ZwI3Qg!8coLj4r3m9uI_EA5hPolvKpSNn4z4A2Pcb8E4A-CykYcM8f3QSgSjqQ_xHGW$>
I'd like to see some response to this question. It's kind of a novel one, as far as I can tell.
Usually, we don't add feature-test macros where the motivation is to mandate the existence of the feature. As was described here:
[Balog]:
> I have one use case in mind. In my projects I usually have a
> configuration/environments checking headers, that looks for compiler,
> language version and platform attributes, with #error if anything is
> not as expected. Especially for things that were assumed and built on.
>
> The paper imposes a strict and reliable order of members, that is not
> unreasonable to assume. And that is easier to check with a related
> than a more generic one.
>
> OTOH my argument in the was that no one is actually swapping.
>
> I'm not in live with the macro and happy to remove it, please make a
> verdict before the postmailing deadline.
And we typically don't add such a macro because for nearly all features, if you simply use the feature, that's mandating its existence, and a compiler that doesn't implement it will just error already. But in this case, "using" the feature doesn't change any code -- it just changes the code gen. On the other hand, as he points out, all the implementations already seem to implement this feature.
Does anybody have an opinion on whether we should or should not have a macro for this feature?
Barry
If the feature test macro is useful in a static_assert, I can see it being somewhat useful, but I don't know that that is currently an SG10 guideline.
Regardless, if someone wants a feature test macro, I would like to see example code that demonstrates such use. A 60 second attempt on my part to come up with a static_assert for this macro didn't yield anything that would be useful.
If re-ordering were permitted, then there could be a macro that is 0 when reordering is on, and something else when reordering is off, and not-present would be left non-portable. That's not the pitch though.
________________________________
From: SG10 <sg10-bounces_at_[hidden]> on behalf of John Spicer via SG10 <sg10_at_[hidden]>
Sent: Sunday, November 1, 2020 10:08 AM
To: Ville Voutilainen via SG10 <sg10_at_[hidden]>
Cc: John Spicer <jhs_at_[hidden]>
Subject: [EXTERNAL] Re: [SG10] P1847 Make declaration order layout mandated
Having a feature test macro for this seems to be of limited usability.
If the macro existed, EDG would probably use our configuration parameter (mentioned in the paper) to control the setting of the macro.
But a user of the macro would probably have to assume that the macro not existing (as would be the case for pre-C++23 compilers) means that the order is the one expected by the paper. So if some older compiler did not use the expected layout, the macro wouldn’t help.
One of the SG10 guidelines is that feature test macros are generally only needed if the programmer would write the code in two different ways depending on the setting of the macro.
So, it doesn’t seem that helpful to me, but I have no objection to adding a macro for this if there is sufficient interest in doing so.
John.
On Nov 1, 2020, at 10:25 AM, Barry Revzin via SG10 <sg10_at_[hidden]<mailto:sg10_at_[hidden]>> wrote:
Hi SG10,
On Thu, Oct 29, 2020 at 7:05 AM Balog Pal via SG10 <sg10_at_[hidden]<mailto:sg10_at_[hidden]>> wrote:
I asked guidance after the last meeting. I did not get a reply back then
and concluded it as confirming the idea to NOT have the macro.
If someone thinks it is needed after all, please say so.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p1847r3.pdf<https://urldefense.com/v3/__http://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p1847r3.pdf__;!!FbZ0ZwI3Qg!8coLj4r3m9uI_EA5hPolvKpSNn4z4A2Pcb8E4A-CykYcM8f3QSgSjqQ_xHGW$>
I'd like to see some response to this question. It's kind of a novel one, as far as I can tell.
Usually, we don't add feature-test macros where the motivation is to mandate the existence of the feature. As was described here:
[Balog]:
> I have one use case in mind. In my projects I usually have a
> configuration/environments checking headers, that looks for compiler,
> language version and platform attributes, with #error if anything is
> not as expected. Especially for things that were assumed and built on.
>
> The paper imposes a strict and reliable order of members, that is not
> unreasonable to assume. And that is easier to check with a related
> than a more generic one.
>
> OTOH my argument in the was that no one is actually swapping.
>
> I'm not in live with the macro and happy to remove it, please make a
> verdict before the postmailing deadline.
And we typically don't add such a macro because for nearly all features, if you simply use the feature, that's mandating its existence, and a compiler that doesn't implement it will just error already. But in this case, "using" the feature doesn't change any code -- it just changes the code gen. On the other hand, as he points out, all the implementations already seem to implement this feature.
Does anybody have an opinion on whether we should or should not have a macro for this feature?
Barry
-- SG10 mailing list SG10_at_[hidden]<mailto:SG10_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/sg10<https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/sg10__;!!FbZ0ZwI3Qg!8coLj4r3m9uI_EA5hPolvKpSNn4z4A2Pcb8E4A-CykYcM8f3QSgSjv-uAWcE$>
Received on 2020-11-01 10:36:22