On Wednesday, 28 June 2017 12:51:10 PDT Micha=C5=82 W. Urba=C5=84czyk wrote=
:
> I feel like I've been catched in a crossfire between vendors who took
> different approaches towards SD-6 adoption. While it may be argued that
> either MS or Qt is at fault (respectively for not implementing useful SD-=
6
> macros or for requiring non-standard feature), I think that problem shoul=
d
> be finally solved by WG21, as stated in p0697r0.

I'm voicing my support for a decision.=20

I am the one who introduced the Qt policy of requiring SD-6 for identifying=
=20
new core language features and, therefore, advising our users to report bug=
s=20
to any compilers that do not support the macros. My hope is that those vend=
ors=20
succumb to user pressure and adopt the macros.

I don't see the point of SD-6 existing if it's not going to be adopted by a=
ll=20
compilers. Therefore, I wish to make it clear I would like it to become par=
t=20
of the standard itself.

The alternative is to drop it completely and stop publishing the macro name=
s.=20
The only worse thing than not having information is to have misleading=20
information. Individual compilers may still use common names, but I expect=
=20
such documents to exist in their own websites. If this is the direction, th=
en=20
we'll go back and identify which compiler versions added which core languag=
e=20
features and at which time. This will happen at the cost of preprocessor ti=
me,=20
for each and every translation unit being compiled.

If the latter happens, it will also seriously hamper any adoption of the=20
Standard *Library* features in Qt. We've been trailing behind because, amon=
g=20
other reasons, we simply can't rely on them existing. Libraries may be=20
upgraded out of cycle with compilers or may be replaced altogether. That me=
ans=20
we can't rely on the compiler version macros or even on the value of=20
__cplusplus. What's more, certain libraries lack a monotonic identifier we=
=20
could use to determine which version they may be.=20

I will not spend any time figuring out library features. If SD-6 is discard=
ed,=20
my recommendation for Qt will be to freeze adoption of the Standard Library=
=20
features at current status quo: C++98 (minus auto_ptr, which we don't use=
=20
anyway).

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1764042.spM5qxDsoT%40tjmaciei-mobl1.

.

The reason SD-6 is separate from the standard is that it provides a
way for an implementation to describes how it fails to conform to the
latest standard. Putting SD-6 in the standard itself would be formally
meaningless: an implementation that conforms to the standard would
define all the macros, and one that doesn't conform could not-conform
by defining none of them, not just the subset matching its
non-conformance.

I definitely support the idea of all compiler vendors implementing
SD-6; it just wouldn't really help the situation to put it into the
International Standard.

Did that make sense? Maybe I've misunderstood exactly how you think we
should put SD-6 into the standard?

Jeffrey

On Wed, Jun 28, 2017 at 2:48 PM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> On Wednesday, 28 June 2017 12:51:10 PDT Micha=C5=82 W. Urba=C5=84czyk wro=
te:
>> I feel like I've been catched in a crossfire between vendors who took
>> different approaches towards SD-6 adoption. While it may be argued that
>> either MS or Qt is at fault (respectively for not implementing useful SD=
-6
>> macros or for requiring non-standard feature), I think that problem shou=
ld
>> be finally solved by WG21, as stated in p0697r0.
>
> I'm voicing my support for a decision.
>
> I am the one who introduced the Qt policy of requiring SD-6 for identifyi=
ng
> new core language features and, therefore, advising our users to report b=
ugs
> to any compilers that do not support the macros. My hope is that those ve=
ndors
> succumb to user pressure and adopt the macros.
>
> I don't see the point of SD-6 existing if it's not going to be adopted by=
 all
> compilers. Therefore, I wish to make it clear I would like it to become p=
art
> of the standard itself.
>
> The alternative is to drop it completely and stop publishing the macro na=
mes.
> The only worse thing than not having information is to have misleading
> information. Individual compilers may still use common names, but I expec=
t
> such documents to exist in their own websites. If this is the direction, =
then
> we'll go back and identify which compiler versions added which core langu=
age
> features and at which time. This will happen at the cost of preprocessor =
time,
> for each and every translation unit being compiled.
>
> If the latter happens, it will also seriously hamper any adoption of the
> Standard *Library* features in Qt. We've been trailing behind because, am=
ong
> other reasons, we simply can't rely on them existing. Libraries may be
> upgraded out of cycle with compilers or may be replaced altogether. That =
means
> we can't rely on the compiler version macros or even on the value of
> __cplusplus. What's more, certain libraries lack a monotonic identifier w=
e
> could use to determine which version they may be.
>
> I will not spend any time figuring out library features. If SD-6 is disca=
rded,
> my recommendation for Qt will be to freeze adoption of the Standard Libra=
ry
> features at current status quo: C++98 (minus auto_ptr, which we don't use
> anyway).
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
> --
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/1764042.spM5qxDsoT%40tjmaciei-mobl1.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANh-dX%3D3f%2BHPrMAiNrDz7aVuC9uCqK5kbTPuPjq2C70=
LEztS0g%40mail.gmail.com.

.

On 29 June 2017 at 01:05, 'Jeffrey Yasskin' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> The reason SD-6 is separate from the standard is that it provides a
> way for an implementation to describes how it fails to conform to the
> latest standard. Putting SD-6 in the standard itself would be formally
> meaningless: an implementation that conforms to the standard would
> define all the macros, and one that doesn't conform could not-conform
> by defining none of them, not just the subset matching its
> non-conformance.
>
> I definitely support the idea of all compiler vendors implementing
> SD-6; it just wouldn't really help the situation to put it into the
> International Standard.
>
> Did that make sense? Maybe I've misunderstood exactly how you think we
> should put SD-6 into the standard?

It's not about how we think it should be put into the standard, but
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0697r0.pdf
mentions such a possibility.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUaxqcpdBZDEiO44SR8koP5%2Bi1N69qLVhz%2BdTEE3MF7Kag%40mail.gmail.com.

.

--001a1149a442c265e605530c71e1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On 28 June 2017 at 14:48, Thiago Macieira <thiago@macieira.org> wrote:

> On Wednesday, 28 June 2017 12:51:10 PDT Micha=C5=82 W. Urba=C5=84czyk wro=
te:
> > I feel like I've been catched in a crossfire between vendors who took
> > different approaches towards SD-6 adoption. While it may be argued that
> > either MS or Qt is at fault (respectively for not implementing useful
> SD-6
> > macros or for requiring non-standard feature), I think that problem
> should
> > be finally solved by WG21, as stated in p0697r0.
>
> I'm voicing my support for a decision.
>
> I am the one who introduced the Qt policy of requiring SD-6 for identifyi=
ng
> new core language features and, therefore, advising our users to report
> bugs
> to any compilers that do not support the macros. My hope is that those
> vendors
> succumb to user pressure and adopt the macros.
>
> I don't see the point of SD-6 existing if it's not going to be adopted by
> all
> compilers. Therefore, I wish to make it clear I would like it to become
> part
> of the standard itself.
>
> The alternative is to drop it completely and stop publishing the macro
> names.
> The only worse thing than not having information is to have misleading
> information. Individual compilers may still use common names, but I expec=
t
> such documents to exist in their own websites. If this is the direction,
> then
> we'll go back and identify which compiler versions added which core
> language
> features and at which time. This will happen at the cost of preprocessor
> time,
> for each and every translation unit being compiled.
>
> If the latter happens, it will also seriously hamper any adoption of the
> Standard *Library* features in Qt. We've been trailing behind because,
> among
> other reasons, we simply can't rely on them existing. Libraries may be
> upgraded out of cycle with compilers or may be replaced altogether. That
> means
> we can't rely on the compiler version macros or even on the value of
> __cplusplus. What's more, certain libraries lack a monotonic identifier w=
e
> could use to determine which version they may be.
>
> I will not spend any time figuring out library features. If SD-6 is
> discarded,
> my recommendation for Qt will be to freeze adoption of the Standard Libra=
ry
> features at current status quo: C++98 (minus auto_ptr, which we don't use
> anyway).


Let's be clear: a WG21 vote does not have the ability to make the feature
test macro recommendations stop existing.

If the committee doesn't want SD-6 to be a standing document, that's a
valid choice, but that doesn't mean implementation behavior will change.
SD-6 has always been documentation of an informal agreement between
participating vendors, maintained in practice by those vendors and other
interested committee members (but open to contribution from all comers), as
a way of making the lives of our users better. I don't see why that would
change if it loses its "standing document" standing -- though some details,
such as where we host the document and what we claim in the introductory
text, might change. We could certainly maintain it similarly to the Itanium
ABI, as a side-document describing implementation details followed by more
or less every vendor except MS =3D)

Regardless of where the document lives, the customers of any particular
vendor can choose to put pressure on that vendor to be compatible with it,
or not, as is their choice.

I do see a path to the feature test macros ceasing to exist: lack of
adoption. If libraries such as boost, Qt, ... decide that they are better
off with only compiler version checks rather than using feature test
macros, then the macros are not fit for purpose and compiler and standard
library vendors are likely to choose to stop adding them. So far, the
evidence we have is that these macros are being used in preference to
compiler version checks, which suggests that the macros do have value in
practice.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOfiQqnfS4DYY3gDo6j1igXMFLC4ppZ%2BrCvzvTGTcSwKg=
LQhAw%40mail.gmail.com.

--001a1149a442c265e605530c71e1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
8 June 2017 at 14:48, Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"mail=
to:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Wednesday, 2=
8 June 2017 12:51:10 PDT Micha=C5=82 W. Urba=C5=84czyk wrote:<br>
&gt; I feel like I&#39;ve been catched in a crossfire between vendors who t=
ook<br>
&gt; different approaches towards SD-6 adoption. While it may be argued tha=
t<br>
&gt; either MS or Qt is at fault (respectively for not implementing useful =
SD-6<br>
&gt; macros or for requiring non-standard feature), I think that problem sh=
ould<br>
&gt; be finally solved by WG21, as stated in p0697r0.<br>
<br>
</span>I&#39;m voicing my support for a decision.<br>
<br>
I am the one who introduced the Qt policy of requiring SD-6 for identifying=
<br>
new core language features and, therefore, advising our users to report bug=
s<br>
to any compilers that do not support the macros. My hope is that those vend=
ors<br>
succumb to user pressure and adopt the macros.<br>
<br>
I don&#39;t see the point of SD-6 existing if it&#39;s not going to be adop=
ted by all<br>
compilers. Therefore, I wish to make it clear I would like it to become par=
t<br>
of the standard itself.<br>
<br>
The alternative is to drop it completely and stop publishing the macro name=
s.<br>
The only worse thing than not having information is to have misleading<br>
information. Individual compilers may still use common names, but I expect<=
br>
such documents to exist in their own websites. If this is the direction, th=
en<br>
we&#39;ll go back and identify which compiler versions added which core lan=
guage<br>
features and at which time. This will happen at the cost of preprocessor ti=
me,<br>
for each and every translation unit being compiled.<br>
<br>
If the latter happens, it will also seriously hamper any adoption of the<br=
>
Standard *Library* features in Qt. We&#39;ve been trailing behind because, =
among<br>
other reasons, we simply can&#39;t rely on them existing. Libraries may be<=
br>
upgraded out of cycle with compilers or may be replaced altogether. That me=
ans<br>
we can&#39;t rely on the compiler version macros or even on the value of<br=
>
__cplusplus. What&#39;s more, certain libraries lack a monotonic identifier=
 we<br>
could use to determine which version they may be.<br>
<br>
I will not spend any time figuring out library features. If SD-6 is discard=
ed,<br>
my recommendation for Qt will be to freeze adoption of the Standard Library=
<br>
features at current status quo: C++98 (minus auto_ptr, which we don&#39;t u=
se<br>
anyway).</blockquote><div><br></div><div>Let&#39;s be clear: a WG21 vote do=
es not have the ability to make the feature test macro recommendations stop=
 existing.</div><div><br></div><div>If the committee doesn&#39;t want SD-6 =
to be a standing document, that&#39;s a valid choice, but that doesn&#39;t =
mean implementation behavior will change. SD-6 has always been documentatio=
n of an informal agreement between participating vendors, maintained in pra=
ctice by those vendors and other interested committee members (but open to =
contribution from all comers), as a way of making the lives of our users be=
tter. I don&#39;t see why that would change if it loses its &quot;standing =
document&quot; standing -- though some details, such as where we host the d=
ocument and what we claim in the introductory text, might change. We could =
certainly maintain it similarly to the Itanium ABI, as a side-document desc=
ribing implementation details followed by more or less every vendor except =
MS =3D)</div><div><br></div><div>Regardless of where the document lives, th=
e customers of any particular vendor can choose to put pressure on that ven=
dor to be compatible with it, or not, as is their choice.</div><div><br></d=
iv><div>I do see a path to the feature test macros ceasing to exist: lack o=
f adoption. If libraries such as boost, Qt, ... decide that they are better=
 off with only compiler version checks rather than using feature test macro=
s, then the macros are not fit for purpose and compiler and standard librar=
y vendors are likely to choose to stop adding them. So far, the evidence we=
 have is that these macros are being used in preference to compiler version=
 checks, which suggests that the macros do have value in practice.</div></d=
iv></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnfS4DYY3gDo6j1igXMFLC4ppZ%2BrC=
vzvTGTcSwKgLQhAw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnfS4DYY3=
gDo6j1igXMFLC4ppZ%2BrCvzvTGTcSwKgLQhAw%40mail.gmail.com</a>.<br />

--001a1149a442c265e605530c71e1--

.

On Wednesday, 28 June 2017 15:05:20 PDT 'Jeffrey Yasskin' via ISO C++ Standard
- Future Proposals wrote:
> The reason SD-6 is separate from the standard is that it provides a
> way for an implementation to describes how it fails to conform to the
> latest standard. Putting SD-6 in the standard itself would be formally
> meaningless: an implementation that conforms to the standard would
> define all the macros, and one that doesn't conform could not-conform
> by defining none of them, not just the subset matching its
> non-conformance.
>
> I definitely support the idea of all compiler vendors implementing
> SD-6; it just wouldn't really help the situation to put it into the
> International Standard.
>
> Did that make sense? Maybe I've misunderstood exactly how you think we
> should put SD-6 into the standard?

I understand what you're saying, but I don't agree with your conclusion.

It would be definitely helpful to us. If a conformant implementation is
required to have it, then it will most likely eventually do. If that were the
case now, then I could simply tell my users "you'll eventually get the
feature", as opposed to them not knowing whether it will ever work.

The same goes for __cplusplus: in Microsoft's compiler and Intel's compiler on
Windows, it's still not set to the value required by the C++11 standard
because they haven't reached full conformance for all core language and
standard library features. When they do, they'll bump the number.

That said, I would seriously encourage vendors to set the individual macros to
the values that indicate that the particular functionality is present and
accounted, regardless of conformance of other features.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3779600.zBvkZadhnz%40tjmaciei-mobl1.

.

On Wed, Jun 28, 2017 at 3:42 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On Wednesday, 28 June 2017 15:05:20 PDT 'Jeffrey Yasskin' via ISO C++ Standard
> - Future Proposals wrote:
>> The reason SD-6 is separate from the standard is that it provides a
>> way for an implementation to describes how it fails to conform to the
>> latest standard. Putting SD-6 in the standard itself would be formally
>> meaningless: an implementation that conforms to the standard would
>> define all the macros, and one that doesn't conform could not-conform
>> by defining none of them, not just the subset matching its
>> non-conformance.
>>
>> I definitely support the idea of all compiler vendors implementing
>> SD-6; it just wouldn't really help the situation to put it into the
>> International Standard.
>>
>> Did that make sense? Maybe I've misunderstood exactly how you think we
>> should put SD-6 into the standard?
>
> I understand what you're saying, but I don't agree with your conclusion.
>
> It would be definitely helpful to us. If a conformant implementation is
> required to have it, then it will most likely eventually do. If that were the
> case now, then I could simply tell my users "you'll eventually get the
> feature", as opposed to them not knowing whether it will ever work.

Ok, that's reasonable: we'd just standardize the macros and their
values, and if a vendor chooses to do something weird during their
not-completely-conformant phase, that's on them.

Thanks,
Jeffrey

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3DAJxmcbkQixZaY%3D8P0kb1BtJto16gS0e9anfFXjFA1ow%40mail.gmail.com.

.

If feature test macros were part of the standard, it would still be a usefu=
l way to tell a 14 compiler from a 17 compiler. At least in theory.=C2=A0

And then hopefully vendors would adopt macros along the way, instead of jus=
t turning them all on at the end when the compiler gets full =E2=80=8Ecompl=
iance.=C2=A0

Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: 'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals
Sent: Wednesday, June 28, 2017 6:05 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] About p0697r0 =E2=80=94 how SD-6 unclear statu=
s proved harmful to me

The reason SD-6 is separate from the standard is that it provides a
way for an implementation to describes how it fails to conform to the
latest standard. Putting SD-6 in the standard itself would be formally
meaningless: an implementation that conforms to the standard would
define all the macros, and one that doesn't conform could not-conform
by defining none of them, not just the subset matching its
non-conformance.

I definitely support the idea of all compiler vendors implementing
SD-6; it just wouldn't really help the situation to put it into the
International Standard.

Did that make sense? Maybe I've misunderstood exactly how you think we
should put SD-6 into the standard?

Jeffrey

On Wed, Jun 28, 2017 at 2:48 PM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> On Wednesday, 28 June 2017 12:51:10 PDT Micha=C5=82 W. Urba=C5=84czyk wro=
te:
>> I feel like I've been catched in a crossfire between vendors who took
>> different approaches towards SD-6 adoption. While it may be argued that
>> either MS or Qt is at fault (respectively for not implementing useful SD=
-6
>> macros or for requiring non-standard feature), I think that problem shou=
ld
>> be finally solved by WG21, as stated in p0697r0.
>
> I'm voicing my support for a decision.
>
> I am the one who introduced the Qt policy of requiring SD-6 for identifyi=
ng
> new core language features and, therefore, advising our users to report b=
ugs
> to any compilers that do not support the macros. My hope is that those ve=
ndors
> succumb to user pressure and adopt the macros.
>
> I don't see the point of SD-6 existing if it's not going to be adopted by=
 all
> compilers. Therefore, I wish to make it clear I would like it to become p=
art
> of the standard itself.
>
> The alternative is to drop it completely and stop publishing the macro na=
mes.
> The only worse thing than not having information is to have misleading
> information. Individual compilers may still use common names, but I expec=
t
> such documents to exist in their own websites. If this is the direction, =
then
> we'll go back and identify which compiler versions added which core langu=
age
> features and at which time. This will happen at the cost of preprocessor =
time,
> for each and every translation unit being compiled.
>
> If the latter happens, it will also seriously hamper any adoption of the
> Standard *Library* features in Qt. We've been trailing behind because, am=
ong
> other reasons, we simply can't rely on them existing. Libraries may be
> upgraded out of cycle with compilers or may be replaced altogether. That =
means
> we can't rely on the compiler version macros or even on the value of
> __cplusplus. What's more, certain libraries lack a monotonic identifier w=
e
> could use to determine which version they may be.
>
> I will not spend any time figuring out library features. If SD-6 is disca=
rded,
> my recommendation for Qt will be to freeze adoption of the Standard Libra=
ry
> features at current status quo: C++98 (minus auto_ptr, which we don't use
> anyway).
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
> --
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/1764042.spM5qxDsoT%40tjmaciei-mobl1.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANh-dX%3D3f%2BHPrMAiNrDz7aVuC9uCqK5kbTPuPjq2C70=
LEztS0g%40mail.gmail.com.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20170628230048.5132370.94373.32118%40gmail.com.

.

On Wednesday, 28 June 2017 15:09:36 PDT Richard Smith wrote:
> If the committee doesn't want SD-6 to be a standing document, that's a
> valid choice, but that doesn't mean implementation behavior will change.
> SD-6 has always been documentation of an informal agreement between
> participating vendors, maintained in practice by those vendors and other
> interested committee members (but open to contribution from all comers), as
> a way of making the lives of our users better. I don't see why that would
> change if it loses its "standing document" standing -- though some details,
> such as where we host the document and what we claim in the introductory
> text, might change. We could certainly maintain it similarly to the Itanium
> ABI, as a side-document describing implementation details followed by more
> or less every vendor except MS =)

Understood.

I suggest updating the wording, if WG21 chooses not to adopt SD-6 into the
language, to be very clear which compilers adopt it. As I said, misleading
information is worse than no information.

> So far, the
> evidence we have is that these macros are being used in preference to
> compiler version checks, which suggests that the macros do have value in
> practice.

Yes, they are useful. This is direct feedback from one of the major
beneficiaries of said feature.

But let me be very clear: Qt will NOT add standard library feature detection.
If SD-6 is not adopted into the standard, we will make exceptions for core
language features, but we will only perform library feature checking based on
a set of macros agreed upon by a majority of library vendors, thereby leaving
the features disabled for any vendor that doesn't adopt the convention. (At
our discretion, we may use a configure-time check for features used in the
implementation and too important to miss, like [1])

That said, our current experience with SD-6 macros for library features and
with __has_include has not been terribly good. See [2] for the latest attempt,
and see Marc Mutz's email about __has_include returning 1 but the file
producing #error.

[1] https://codereview.qt-project.org/196612
[2] http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/thread/qthread.h?
h=dev#n45

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1903736.KF1V56UY5x%40tjmaciei-mobl1.

.

On Wednesday, 28 June 2017 15:47:29 PDT 'Jeffrey Yasskin' via ISO C++ Standard
- Future Proposals wrote:
> > It would be definitely helpful to us. If a conformant implementation is
> > required to have it, then it will most likely eventually do. If that were
> > the case now, then I could simply tell my users "you'll eventually get
> > the feature", as opposed to them not knowing whether it will ever work.
>
> Ok, that's reasonable: we'd just standardize the macros and their
> values, and if a vendor chooses to do something weird during their
> not-completely-conformant phase, that's on them.

Well, kinda. If they set the macro to the expected value before the feature is
conformant, then it's even worse than not having the macro in the first place.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3779603.CTvSGuCUkm%40tjmaciei-mobl1.

.

--001a1149e1f41f85e505530d7e5a
Content-Type: text/plain; charset="UTF-8"

On 28 June 2017 at 16:04, Thiago Macieira <thiago@macieira.org> wrote:

> On Wednesday, 28 June 2017 15:09:36 PDT Richard Smith wrote:
> > If the committee doesn't want SD-6 to be a standing document, that's a
> > valid choice, but that doesn't mean implementation behavior will change.
> > SD-6 has always been documentation of an informal agreement between
> > participating vendors, maintained in practice by those vendors and other
> > interested committee members (but open to contribution from all comers),
> as
> > a way of making the lives of our users better. I don't see why that would
> > change if it loses its "standing document" standing -- though some
> details,
> > such as where we host the document and what we claim in the introductory
> > text, might change. We could certainly maintain it similarly to the
> Itanium
> > ABI, as a side-document describing implementation details followed by
> more
> > or less every vendor except MS =)
>
> Understood.
>
> I suggest updating the wording, if WG21 chooses not to adopt SD-6 into the
> language, to be very clear which compilers adopt it. As I said, misleading
> information is worse than no information.


That seems a little problematic -- I'd expect vendors to document which
versions of the recommendations they support, since a new version of a
document can't give an accurate list of which vendors *will* support it,
and in which versions of their implementations. But explicitly saying "not
all compilers support this, consult your documentation" seems fine, and we
could reasonably do that right now.

> So far, the
> > evidence we have is that these macros are being used in preference to
> > compiler version checks, which suggests that the macros do have value in
> > practice.
>
> Yes, they are useful. This is direct feedback from one of the major
> beneficiaries of said feature.
>
> But let me be very clear: Qt will NOT add standard library feature
> detection.
> If SD-6 is not adopted into the standard, we will make exceptions for core
> language features, but we will only perform library feature checking based
> on
> a set of macros agreed upon by a majority of library vendors, thereby
> leaving
> the features disabled for any vendor that doesn't adopt the convention. (At
> our discretion, we may use a configure-time check for features used in the
> implementation and too important to miss, like [1])
>
> That said, our current experience with SD-6 macros for library features and
> with __has_include has not been terribly good. See [2] for the latest
> attempt,
> and see Marc Mutz's email about __has_include returning 1 but the file
> producing #error.
>

Yes, expecting __has_include to be sufficient to detect library headers was
a well-intentioned mistake. We seem to have informal consensus within SG10
to switch to using __cpp_lib_* macros for this purpose.


> [1] https://codereview.qt-project.org/196612
> [2] http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/thread
> /qthread.h?
> h=dev#n45
> <http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/thread/qthread.h?h=dev#n45>
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/1903736.KF1V56UY5x%40tjmaciei-mobl1.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn2wJNWW1ee_8iV%3Da4HcJKtQnFNdez9Bph8R6SPX3JjWA%40mail.gmail.com.

--001a1149e1f41f85e505530d7e5a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
8 June 2017 at 16:04, Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"mail=
to:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span>On Wednesday, 28 June 2017=
 15:09:36 PDT Richard Smith wrote:<br>
&gt; If the committee doesn&#39;t want SD-6 to be a standing document, that=
&#39;s a<br>
&gt; valid choice, but that doesn&#39;t mean implementation behavior will c=
hange.<br>
&gt; SD-6 has always been documentation of an informal agreement between<br=
>
&gt; participating vendors, maintained in practice by those vendors and oth=
er<br>
&gt; interested committee members (but open to contribution from all comers=
), as<br>
&gt; a way of making the lives of our users better. I don&#39;t see why tha=
t would<br>
&gt; change if it loses its &quot;standing document&quot; standing -- thoug=
h some details,<br>
&gt; such as where we host the document and what we claim in the introducto=
ry<br>
&gt; text, might change. We could certainly maintain it similarly to the It=
anium<br>
&gt; ABI, as a side-document describing implementation details followed by =
more<br>
&gt; or less every vendor except MS =3D)<br>
<br>
</span>Understood.<br>
<br>
I suggest updating the wording, if WG21 chooses not to adopt SD-6 into the<=
br>
language, to be very clear which compilers adopt it. As I said, misleading<=
br>
information is worse than no information.</blockquote><div><br></div><div>T=
hat seems a little problematic -- I&#39;d expect vendors to document which =
versions of the recommendations they support, since a new version of a docu=
ment can&#39;t give an accurate list of which vendors *will* support it, an=
d in which versions of their implementations. But explicitly saying &quot;n=
ot all compilers support this, consult your documentation&quot; seems fine,=
 and we could reasonably do that right now.</div><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><span>
&gt; So far, the<br>
&gt; evidence we have is that these macros are being used in preference to<=
br>
&gt; compiler version checks, which suggests that the macros do have value =
in<br>
&gt; practice.<br>
<br>
</span>Yes, they are useful. This is direct feedback from one of the major<=
br>
beneficiaries of said feature.<br>
<br>
But let me be very clear: Qt will NOT add standard library feature detectio=
n.<br>
If SD-6 is not adopted into the standard, we will make exceptions for core<=
br>
language features, but we will only perform library feature checking based =
on<br>
a set of macros agreed upon by a majority of library vendors, thereby leavi=
ng<br>
the features disabled for any vendor that doesn&#39;t adopt the convention.=
 (At<br>
our discretion, we may use a configure-time check for features used in the<=
br>
implementation and too important to miss, like [1])<br>
<br>
That said, our current experience with SD-6 macros for library features and=
<br>
with __has_include has not been terribly good. See [2] for the latest attem=
pt,<br>
and see Marc Mutz&#39;s email about __has_include returning 1 but the file<=
br>
producing #error.<br></blockquote><div><br></div><div>Yes, expecting __has_=
include to be sufficient to detect library headers was a well-intentioned m=
istake. We seem to have informal consensus within SG10 to switch to using _=
_cpp_lib_* macros for this purpose.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
[1] <a href=3D"https://codereview.qt-project.org/196612" rel=3D"noreferrer"=
 target=3D"_blank">https://codereview.qt-project.<wbr>org/196612</a><br>
[2] <a href=3D"http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/thread=
/qthread.h?h=3Ddev#n45" rel=3D"noreferrer" target=3D"_blank">http://code.qt=
..io/cgit/qt/qtba<wbr>se.git/tree/src/corelib/thread<wbr>/qthread.h?<br>
h=3Ddev#n45</a><br>
<span><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/1903736.KF1V56UY5x%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/is<=
wbr>ocpp.org/d/msgid/std-proposals<wbr>/1903736.KF1V56UY5x%40tjmaciei<wbr>-=
mobl1</a>.<br>
</blockquote></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn2wJNWW1ee_8iV%3Da4HcJKtQnFNde=
z9Bph8R6SPX3JjWA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn2wJNWW1=
ee_8iV%3Da4HcJKtQnFNdez9Bph8R6SPX3JjWA%40mail.gmail.com</a>.<br />

--001a1149e1f41f85e505530d7e5a--

.

On Wednesday, 28 June 2017 16:24:38 PDT Richard Smith wrote:
> > I suggest updating the wording, if WG21 chooses not to adopt SD-6 into the
> > language, to be very clear which compilers adopt it. As I said, misleading
> > information is worse than no information.
>
> That seems a little problematic -- I'd expect vendors to document which
> versions of the recommendations they support, since a new version of a
> document can't give an accurate list of which vendors *will* support it,
> and in which versions of their implementations. But explicitly saying "not
> all compilers support this, consult your documentation" seems fine, and we
> could reasonably do that right now.

Right, that would be enough.

Of course, the document can link to the compiler documentation page that
documents that the compiler does adopt the convention. I'd expect compilers
that do so to make a commitment that they will continue following the
recommendations, at least until a major force requires a change of policy.

> > That said, our current experience with SD-6 macros for library features
> > and
> > with __has_include has not been terribly good. See [2] for the latest
> > attempt,
> > and see Marc Mutz's email about __has_include returning 1 but the file
> > producing #error.
>
> Yes, expecting __has_include to be sufficient to detect library headers was
> a well-intentioned mistake. We seem to have informal consensus within SG10
> to switch to using __cpp_lib_* macros for this purpose.

The feature is still salvageable. All that needs to happen is that the #error
be removed from the header.

Preventing the header from being used while the compiler is running with an
earlier version of the standard can be solved by other means. My suggestion to
gcc and libstdc++ is to use different include paths. It currently searches in

 /usr/include/c++/$VER/
 /usr/include/c++/$VER/$ARCH
 /usr/include/c++/$VER/backward

The headers introduced in C++11 could live inside a "c++11" (or "cxx11" if
needed) subdir, like that "backward" one

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2253258.Vu4drnISy3%40tjmaciei-mobl1.

.

On 06/29/17 01:09, Richard Smith wrote:
>
> I do see a path to the feature test macros ceasing to exist: lack of
> adoption. If libraries such as boost, Qt, ... decide that they are
> better off with only compiler version checks rather than using feature
> test macros, then the macros are not fit for purpose and compiler and
> standard library vendors are likely to choose to stop adding them. So
> far, the evidence we have is that these macros are being used in
> preference to compiler version checks, which suggests that the macros do
> have value in practice.

I can share the approach we took in Boost.Config, the central library
that is used by other Boost libraries and Boost users to detect compiler
and standard library features and bugs. Thanks to Boost.Config, most
other libraries don't need to perform any checks on their own.

Compiler-defined macros are tested to detect language features, although
that doesn't eliminate compiler version checks because, well, compilers
are buggy. I think we had a case when a compiler defined SD-6 macro but
the feature was too broken to be used.

Library-defined macros are not used at all because in order to use them
a library header has to be included. Including a standard library header
is harmful for compile times, and since that header or feature is not
used by Boost.Config and likely its user, that overhead goes to drain.
We do use __has_include though, both in Boost.Config and other
libraries, to detect presence of headers (from standard library and not).

Compiler checks are not removed, and would not be removed even if all
compilers were bug-free and we used the library-defined SD-6 macros.
There are a number of features not covered by SD-6 that we still need to
know, like target architecture, availability of instruction set
extensions, endianness, availability of some pragmas, intrinsics and
attributes (yes, there is __has_cpp_attribute, but it doesn't cover
things like __forceinline). Besides, there are compilers that don't
support SD-6, including all C++03 compilers.

I think Boost.Config case is quite representative because I've seen many
libraries using one common place for compatibility checks, which is used
throughout the code base, and I can see many of our concerns would be
valid for them as well.

In my opinion, SD-6 doesn't work as a replacement for compiler checks.
In particular, the library-defined macros proved to have very limited
usability. I think, that department could be helped if all macros were
guaranteed to be defined by a single separate header with nothing else
in it (e.g. call it <features>). Regardless, SD-6 can only work as an
addition to the compiler checks, as a new way of detecting features in
addition to the compiler-specific macros.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a4dc4e07-f856-558b-132d-15df522c92dc%40gmail.com.

.

Andrey Semashev wrote:

> In particular, the library-defined macros proved to have very limited
> usability. I think, that department could be helped if all macros were
> guaranteed to be defined by a single separate header with nothing else
> in it (e.g. call it <features>).

This times a million.

The language macros are useful, but the library macros are useless because
they are defined in the wrong place.

I told SG-10 this years ago before SD-6 had really taken off, but my
suggestion of putting the library macros in one file was not taken.

If these macros actually get standardized, that should be revisited.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/59560a9f.2797500a.6bfe0.82dc%40mx.google.com.

.

------=_Part_669_1020061522.1498878201648
Content-Type: text/plain; charset="UTF-8"

If they were all in one header you still might not know which header to include.  It's almost like you want a tool that took a macro name and value and tell you if there was no support or else tell the include file and Lang version required.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1792d6a9-1462-4974-a664-0c082d2207fe%40isocpp.org.

------=_Part_669_1020061522.1498878201648--

.

On 2017-07-01 05:03, 3dw4rd@verizon.net wrote:
> If they were all in one header you still might not know which header
> to include.

You could use a header that already existed in C++98 (<cstddef>, e.g.),
or SD-6 could mandate that if the header (<features>, to be bikeshedded)
is reported as existing from __has_include, then it must be include-able
(no #error on __cplusplus, no actual C++ in there, just cpp stuff). Then
one could write

    #ifdef __has_include
    #  if __has_include(<features>)
    #    include <features>
    #  endif
    #endif

in one's project's configuration header file (config.h for autotools
e.g.) and assume the header to be included in all implementation files.

Thanks,
Marc



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a85d358004741ce68dbdd811f27f795c%40kdab.com.

.