Topic: Testing for supported features: Per-feature
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 26 Jul 2015 20:57:34 +0300
Raw View
On 26 July 2015 at 20:42, denis bider <isocppgroup@denisbider.com> wrote:
> A common issue in libraries with similar goals is how to detect that a
> particular language feature is implemented, so as to either make use of it
> or not. Currently, in most cases, this requires testing macros for specific
> compiler versions.
Some implementations support these:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4440.html
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: denis bider <isocppgroup@denisbider.com>
Date: Sun, 26 Jul 2015 13:35:01 -0700 (PDT)
Raw View
------=_Part_2396_838705685.1437942901705
Content-Type: multipart/alternative;
boundary="----=_Part_2397_863658984.1437942901705"
------=_Part_2397_863658984.1437942901705
Content-Type: text/plain; charset=UTF-8
This is nice and all, but it's a *lot* of bureaucracy for a non-general
solution that needs maintenance with every new language version; and leaves
out niche situations that sentinel compilation would solve (e.g.
implementation differences between compilers that *claim* to implement the
same feature).
On Sunday, July 26, 2015 at 11:57:35 AM UTC-6, Ville Voutilainen wrote:
>
> On 26 July 2015 at 20:42, denis bider <isocp...@denisbider.com
> <javascript:>> wrote:
> > A common issue in libraries with similar goals is how to detect that a
> > particular language feature is implemented, so as to either make use of
> it
> > or not. Currently, in most cases, this requires testing macros for
> specific
> > compiler versions.
>
> Some implementations support these:
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4440.html
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2397_863658984.1437942901705
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This is nice and all, but it's a <em>lot</em> of burea=
ucracy for a non-general solution that needs maintenance with every new lan=
guage version; and leaves out niche situations that sentinel compilation wo=
uld solve (e.g. implementation differences between compilers that <em>claim=
</em> to implement the same feature).<br><br>On Sunday, July 26, 2015 at 11=
:57:35 AM UTC-6, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: r=
gb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">On 26=
July 2015 at 20:42, denis bider <<a onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow">isocp..=
..@denisbider.com</a>> wrote:
<br>> A common issue in libraries with similar goals is how to detect th=
at a
<br>> particular language feature is implemented, so as to either make u=
se of it
<br>> or not. Currently, in most cases, this requires testing macros for=
specific
<br>> compiler versions.
<br>
<br>Some implementations support these:
<br><a onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3=
A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2015%2Fn4440.htm=
l\46sa\75D\46sntz\0751\46usg\75AFQjCNGChifP8BumVKB0Vy9FEzTq8kFoXA';retu=
rn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A=
%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2015%2Fn4440.html=
\46sa\75D\46sntz\0751\46usg\75AFQjCNGChifP8BumVKB0Vy9FEzTq8kFoXA';retur=
n true;" href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4440.=
html" target=3D"_blank" rel=3D"nofollow">http://open-std.org/JTC1/SC22/WG21=
/docs/papers/2015/n4440.html</a>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2397_863658984.1437942901705--
------=_Part_2396_838705685.1437942901705--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 26 Jul 2015 15:54:07 -0700
Raw View
On Sunday 26 July 2015 13:35:01 denis bider wrote:
> This is nice and all, but it's a *lot* of bureaucracy for a non-general
> solution that needs maintenance with every new language version; and leaves
> out niche situations that sentinel compilation would solve (e.g.
> implementation differences between compilers that *claim* to implement the
> same feature).
What bureaucracy are you talking about?
The up-to-date list is
http://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations
Sentinel compilation would imply a major feature to the language. You can
already do that with a configure script, if you want, though.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: denis bider <isocppgroup@denisbider.com>
Date: Sun, 26 Jul 2015 18:03:16 -0700 (PDT)
Raw View
------=_Part_0_1499831596.1437958996961
Content-Type: multipart/alternative;
boundary="----=_Part_1_57966111.1437958996966"
------=_Part_1_57966111.1437958996966
Content-Type: text/plain; charset=UTF-8
Maintaining that registry, now and forever in the future, does not seem
like a bureaucracy to you?
It's extra work for language maintainers; it isn't general; and it doesn't
provide a way to test for differences in compiler implementations.
> Sentinel compilation would imply a major feature to the language.
> You can already do that with a configure script, if you want, though.
That opens a whole other can of worms, which sentinel compilation would
make it easy to avoid.
On Sunday, July 26, 2015 at 4:54:11 PM UTC-6, Thiago Macieira wrote:
> On Sunday 26 July 2015 13:35:01 denis bider wrote:
> > This is nice and all, but it's a *lot* of bureaucracy for a non-general
> > solution that needs maintenance with every new language version; and
> leaves
> > out niche situations that sentinel compilation would solve (e.g.
> > implementation differences between compilers that *claim* to implement
> the
> > same feature).
>
> What bureaucracy are you talking about?
>
> The up-to-date list is
>
> http://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations
>
> Sentinel compilation would imply a major feature to the language. You can
> already do that with a configure script, if you want, though.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1_57966111.1437958996966
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Maintaining that registry, now and forever in the fut=
ure, does not seem like a bureaucracy to you?</div><div><br></div><div>It&#=
39;s extra work for language maintainers; it isn't general; and it does=
n't provide a way to test for differences in compiler implementations.<=
/div><div><br></div><div><br></div><div>> Sentinel compilation would imp=
ly a major feature to the language.</div><div>> You can already do that =
with a configure script, if you want, though. </div><div><br></div><div>Tha=
t opens a whole other can of worms, which sentinel compilation would make i=
t easy to avoid.<br><br><br>On Sunday, July 26, 2015 at 4:54:11 PM UTC-6, T=
hiago Macieira wrote:</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 2=
04); border-left-width: 1px; border-left-style: solid;">On Sunday 26 July 2=
015 13:35:01 denis bider wrote:
<br>> This is nice and all, but it's a *lot* of bureaucracy for a no=
n-general=20
<br>> solution that needs maintenance with every new language version; a=
nd leaves=20
<br>> out niche situations that sentinel compilation would solve (e.g.
<br>> implementation differences between compilers that *claim* to imple=
ment the=20
<br>> same feature).
<br>
<br>What bureaucracy are you talking about?
<br>
<br>The up-to-date list is=20
<br><a onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3=
A%2F%2Fisocpp.org%2Fstd%2Fstanding-documents%2Fsd-6-sg10-feature-test-recom=
mendations\46sa\75D\46sntz\0751\46usg\75AFQjCNE9iXtekR38eFtgqmELK3rw2ss-xw&=
#39;;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\=
75http%3A%2F%2Fisocpp.org%2Fstd%2Fstanding-documents%2Fsd-6-sg10-feature-te=
st-recommendations\46sa\75D\46sntz\0751\46usg\75AFQjCNE9iXtekR38eFtgqmELK3r=
w2ss-xw';return true;" href=3D"http://isocpp.org/std/standing-documents=
/sd-6-sg10-feature-test-recommendations" target=3D"_blank" rel=3D"nofollow"=
>http://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommenda=
tions</a>
<br>
<br>Sentinel compilation would imply a major feature to the language. You c=
an=20
<br>already do that with a configure script, if you want, though.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.=
href=3D'http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;=
" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofollow">macieira=
..info</a> - thiago (AT) <a onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJd=
o5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http=
://www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" href=3D"http://kde.o=
rg" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1_57966111.1437958996966--
------=_Part_0_1499831596.1437958996961--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 26 Jul 2015 18:17:35 -0700
Raw View
On Sunday 26 July 2015 18:03:16 denis bider wrote:
> Maintaining that registry, now and forever in the future, does not seem
> like a bureaucracy to you?
Yes, it is. But it's something readily accessible now, which is more than any
other alternatives.
> It's extra work for language maintainers; it isn't general; and it doesn't
> provide a way to test for differences in compiler implementations.
True, but there shouldn't be differences in compiler implementations. Different
revisions of a feature can be marked by different dates on the feature macro,
such as __cpp_constexpr has done.
Compiler bugs should be fixed. And besides, you can't test for all compiler
bugs this way.
> > Sentinel compilation would imply a major feature to the language.
> > You can already do that with a configure script, if you want, though.
>
> That opens a whole other can of worms, which sentinel compilation would
> make it easy to avoid.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: denis bider <isocppgroup@denisbider.com>
Date: Sun, 26 Jul 2015 19:36:07 -0700 (PDT)
Raw View
------=_Part_2490_1839548734.1437964567810
Content-Type: multipart/alternative;
boundary="----=_Part_2491_978443330.1437964567810"
------=_Part_2491_978443330.1437964567810
Content-Type: text/plain; charset=UTF-8
It is not, in fact, readily accessible now. It is an inferior solution that
has not yet been implemented by any compiler that I have access to. It will
require maintenance for any new language features added, ever. Whether
today, five years from now, 10 years from now - any new feature that is
added will have to be added to the registry. There will be problems when a
feature is implemented this way by this compiler, that way by another.
There will be problems when a feature is considered part of another
feature, but compiler implementers treat them separately.
> True, but there shouldn't be differences in compiler implementations.
There is a tremendous amount of hubris in this single word, "should". If
you *had the power* to cause compiler implementations to be consistent, you
wouldn't need this registry to begin with.
I'm betting that the reason per-feature macros were not specified earlier;
so that we could use them now; was still more "should" reasoning, of the
type you espouse above. I'm betting that the standards body thought
compilers "should" implement each language version as a whole, instead of
piecemeal. I'm betting they thought that adding per-feature macros, at that
time, would have encouraged piecemeal implementation. They thought
compilers "should" implement a whole standard version at a time, and update
their __cplusplus macro value correspondingly.
Now, look at what we actually got. All because some well-meaning people, a
few years in the past, thought that compilers "should".
> And besides, you can't test for all compiler bugs this way.
Not all, but one can test for most everything that has to do with syntax.
On Sunday, July 26, 2015 at 7:17:41 PM UTC-6, Thiago Macieira wrote:
> On Sunday 26 July 2015 18:03:16 denis bider wrote:
> > Maintaining that registry, now and forever in the future, does not seem
> > like a bureaucracy to you?
>
> Yes, it is. But it's something readily accessible now, which is more than
> any
> other alternatives.
>
> > It's extra work for language maintainers; it isn't general; and it
> doesn't
> > provide a way to test for differences in compiler implementations.
>
> True, but there shouldn't be differences in compiler implementations.
> Different
> revisions of a feature can be marked by different dates on the feature
> macro,
> such as __cpp_constexpr has done.
>
> Compiler bugs should be fixed. And besides, you can't test for all
> compiler
> bugs this way.
>
> > > Sentinel compilation would imply a major feature to the language.
> > > You can already do that with a configure script, if you want, though.
> >
> > That opens a whole other can of worms, which sentinel compilation would
> > make it easy to avoid.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2491_978443330.1437964567810
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>It is not, in fact, readily accessible now. It is an =
inferior solution that has not yet been implemented by any compiler that I =
have access to. It will require maintenance for any new language features a=
dded, ever. Whether today, five years from now, 10 years from now - any new=
feature that is added will have to be added to the registry. There will be=
problems when a feature is implemented this way by this compiler, that way=
by another. There will be problems when a feature is considered part of an=
other feature, but compiler implementers treat them separately.</div><div><=
br></div><div>> True, but there shouldn't be differences in compiler=
implementations.</div><div><br></div><div>There is a tremendous amount of =
hubris in this single word, "should". If you <em>had the power</e=
m> to cause compiler implementations to be consistent, you wouldn't nee=
d this registry to begin with.</div><div><br></div><div>I'm betting tha=
t the reason per-feature macros were not specified earlier; so that we coul=
d use them=C2=A0now;=C2=A0was still more "should" reasoning, of t=
he type you espouse above. I'm betting that the standards body thought =
compilers "should" implement each language version as a whole, in=
stead of piecemeal. I'm betting they thought that adding per-feature ma=
cros, at that time, would have encouraged piecemeal implementation. They th=
ought compilers "should" implement a whole standard version at a =
time, and update their __cplusplus macro value correspondingly.</div><div><=
br></div><div>Now, look at what we actually got. All because some well-mean=
ing people, a few years in the past, thought that compilers "should&qu=
ot;.</div><div><br></div><div><br></div><div>> And besides, you can'=
t test for all compiler=C2=A0bugs this way. </div><div><br></div><div>Not a=
ll, but one can test for most everything that has to do with syntax.</div><=
div><br><br>On Sunday, July 26, 2015 at 7:17:41 PM UTC-6, Thiago Macieira w=
rote:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left=
-width: 1px; border-left-style: solid;">On Sunday 26 July 2015 18:03:16 den=
is bider wrote:
<br>> Maintaining that registry, now and forever in the future, does not=
seem
<br>> like a bureaucracy to you?
<br>
<br>Yes, it is. But it's something readily accessible now, which is mor=
e than any=20
<br>other alternatives.
<br>
<br>> It's extra work for language maintainers; it isn't general=
; and it doesn't
<br>> provide a way to test for differences in compiler implementations.
<br>
<br>True, but there shouldn't be differences in compiler implementation=
s. Different=20
<br>revisions of a feature can be marked by different dates on the feature =
macro,=20
<br>such as __cpp_constexpr has done.
<br>
<br>Compiler bugs should be fixed. And besides, you can't test for all =
compiler=20
<br>bugs this way.
<br>
<br>> > Sentinel compilation would imply a major feature to the langu=
age.
<br>> > You can already do that with a configure script, if you want,=
though.
<br>>=20
<br>> That opens a whole other can of worms, which sentinel compilation =
would
<br>> make it easy to avoid.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.=
href=3D'http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;=
" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofollow">macieira=
..info</a> - thiago (AT) <a onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJd=
o5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http=
://www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" href=3D"http://kde.o=
rg" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2491_978443330.1437964567810--
------=_Part_2490_1839548734.1437964567810--
.
Author: denis bider <isocppgroup@denisbider.com>
Date: Sun, 26 Jul 2015 19:43:43 -0700 (PDT)
Raw View
------=_Part_466_1099434043.1437965023472
Content-Type: multipart/alternative;
boundary="----=_Part_467_2063905445.1437965023472"
------=_Part_467_2063905445.1437965023472
Content-Type: text/plain; charset=UTF-8
Pardon me, I do have access to Clang, which implements that.
Of course, I don't actually use *Clang*... ;)
On Sunday, July 26, 2015 at 8:36:07 PM UTC-6, denis bider wrote:
> It is not, in fact, readily accessible now. It is an inferior solution
> that has not yet been implemented by any compiler that I have access to. It
> will require maintenance for any new language features added, ever. Whether
> today, five years from now, 10 years from now - any new feature that is
> added will have to be added to the registry. There will be problems when a
> feature is implemented this way by this compiler, that way by another.
> There will be problems when a feature is considered part of another
> feature, but compiler implementers treat them separately.
>
> > True, but there shouldn't be differences in compiler implementations.
>
> There is a tremendous amount of hubris in this single word, "should". If
> you *had the power* to cause compiler implementations to be consistent,
> you wouldn't need this registry to begin with.
>
> I'm betting that the reason per-feature macros were not specified earlier;
> so that we could use them now; was still more "should" reasoning, of the
> type you espouse above. I'm betting that the standards body thought
> compilers "should" implement each language version as a whole, instead of
> piecemeal. I'm betting they thought that adding per-feature macros, at that
> time, would have encouraged piecemeal implementation. They thought
> compilers "should" implement a whole standard version at a time, and update
> their __cplusplus macro value correspondingly.
>
> Now, look at what we actually got. All because some well-meaning people, a
> few years in the past, thought that compilers "should".
>
>
> > And besides, you can't test for all compiler bugs this way.
>
> Not all, but one can test for most everything that has to do with syntax.
>
>
> On Sunday, July 26, 2015 at 7:17:41 PM UTC-6, Thiago Macieira wrote:
>
>> On Sunday 26 July 2015 18:03:16 denis bider wrote:
>> > Maintaining that registry, now and forever in the future, does not seem
>> > like a bureaucracy to you?
>>
>> Yes, it is. But it's something readily accessible now, which is more than
>> any
>> other alternatives.
>>
>> > It's extra work for language maintainers; it isn't general; and it
>> doesn't
>> > provide a way to test for differences in compiler implementations.
>>
>> True, but there shouldn't be differences in compiler implementations.
>> Different
>> revisions of a feature can be marked by different dates on the feature
>> macro,
>> such as __cpp_constexpr has done.
>>
>> Compiler bugs should be fixed. And besides, you can't test for all
>> compiler
>> bugs this way.
>>
>> > > Sentinel compilation would imply a major feature to the language.
>> > > You can already do that with a configure script, if you want, though.
>> >
>> > That opens a whole other can of worms, which sentinel compilation would
>> > make it easy to avoid.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel Open Source Technology Center
>> PGP/GPG: 0x6EF45358; fingerprint:
>> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>>
>>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_467_2063905445.1437965023472
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Pardon me, I do have access to Clang, which implement=
s that.</div><div><br></div><div>Of course, I don't actually use <em>Cl=
ang</em>... ;)</div><div>=C2=A0<br><br>On Sunday, July 26, 2015 at 8:36:07 =
PM UTC-6, denis bider wrote:</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr"><div>It is not, in fact, readily accessible now. It is an inferior=
solution that has not yet been implemented by any compiler that I have acc=
ess to. It will require maintenance for any new language features added, ev=
er. Whether today, five years from now, 10 years from now - any new feature=
that is added will have to be added to the registry. There will be problem=
s when a feature is implemented this way by this compiler, that way by anot=
her. There will be problems when a feature is considered part of another fe=
ature, but compiler implementers treat them separately.</div><div><br></div=
><div>> True, but there shouldn't be differences in compiler impleme=
ntations.</div><div><br></div><div>There is a tremendous amount of hubris i=
n this single word, "should". If you <em>had the power</em> to ca=
use compiler implementations to be consistent, you wouldn't need this r=
egistry to begin with.</div><div><br></div><div>I'm betting that the re=
ason per-feature macros were not specified earlier; so that we could use th=
em=C2=A0now;=C2=A0was still more "should" reasoning, of the type =
you espouse above. I'm betting that the standards body thought compiler=
s "should" implement each language version as a whole, instead of=
piecemeal. I'm betting they thought that adding per-feature macros, at=
that time, would have encouraged piecemeal implementation. They thought co=
mpilers "should" implement a whole standard version at a time, an=
d update their __cplusplus macro value correspondingly.</div><div><br></div=
><div>Now, look at what we actually got. All because some well-meaning peop=
le, a few years in the past, thought that compilers "should".</di=
v><div><br></div><div><br></div><div>> And besides, you can't test f=
or all compiler=C2=A0bugs this way. </div><div><br></div><div>Not all, but =
one can test for most everything that has to do with syntax.</div><div><br>=
<br>On Sunday, July 26, 2015 at 7:17:41 PM UTC-6, Thiago Macieira wrote:</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pa=
dding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: =
1px; border-left-style: solid;">On Sunday 26 July 2015 18:03:16 denis bider=
wrote:
<br>> Maintaining that registry, now and forever in the future, does not=
seem
<br>> like a bureaucracy to you?
<br>
<br>Yes, it is. But it's something readily accessible now, which is mor=
e than any=20
<br>other alternatives.
<br>
<br>> It's extra work for language maintainers; it isn't general=
; and it doesn't
<br>> provide a way to test for differences in compiler implementations.
<br>
<br>True, but there shouldn't be differences in compiler implementation=
s. Different=20
<br>revisions of a feature can be marked by different dates on the feature =
macro,=20
<br>such as __cpp_constexpr has done.
<br>
<br>Compiler bugs should be fixed. And besides, you can't test for all =
compiler=20
<br>bugs this way.
<br>
<br>> > Sentinel compilation would imply a major feature to the langu=
age.
<br>> > You can already do that with a configure script, if you want,=
though.
<br>>=20
<br>> That opens a whole other can of worms, which sentinel compilation =
would
<br>> make it easy to avoid.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.=
href=3D'http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;=
" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofollow">macieira=
..info</a> - thiago (AT) <a onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJd=
o5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http=
://www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" href=3D"http://kde.o=
rg" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_467_2063905445.1437965023472--
------=_Part_466_1099434043.1437965023472--
.
Author: denis bider <isocppgroup@denisbider.com>
Date: Sun, 26 Jul 2015 19:51:16 -0700 (PDT)
Raw View
------=_Part_2486_1244313517.1437965476328
Content-Type: multipart/alternative;
boundary="----=_Part_2487_997462932.1437965476328"
------=_Part_2487_997462932.1437965476328
Content-Type: text/plain; charset=UTF-8
Sorry for the spam, but -
With respect to this:
> > And besides, you can't test for all compiler bugs this way.
> Not all, but one can test for most everything that has to do with syntax.
You can put a *static_assert* in the test block, too, and thereby test for
anything that the compiler can evaluate at compile time; *including*
whether the compiler can evaluate what you're testing, in the first place.
On Sunday, July 26, 2015 at 8:43:43 PM UTC-6, denis bider wrote:
> Pardon me, I do have access to Clang, which implements that.
>
> Of course, I don't actually use *Clang*... ;)
>
>
> On Sunday, July 26, 2015 at 8:36:07 PM UTC-6, denis bider wrote:
>
>> It is not, in fact, readily accessible now. It is an inferior solution
>> that has not yet been implemented by any compiler that I have access to. It
>> will require maintenance for any new language features added, ever. Whether
>> today, five years from now, 10 years from now - any new feature that is
>> added will have to be added to the registry. There will be problems when a
>> feature is implemented this way by this compiler, that way by another.
>> There will be problems when a feature is considered part of another
>> feature, but compiler implementers treat them separately.
>>
>> > True, but there shouldn't be differences in compiler implementations.
>>
>> There is a tremendous amount of hubris in this single word, "should". If
>> you *had the power* to cause compiler implementations to be consistent,
>> you wouldn't need this registry to begin with.
>>
>> I'm betting that the reason per-feature macros were not specified
>> earlier; so that we could use them now; was still more "should" reasoning,
>> of the type you espouse above. I'm betting that the standards body thought
>> compilers "should" implement each language version as a whole, instead of
>> piecemeal. I'm betting they thought that adding per-feature macros, at that
>> time, would have encouraged piecemeal implementation. They thought
>> compilers "should" implement a whole standard version at a time, and update
>> their __cplusplus macro value correspondingly.
>>
>> Now, look at what we actually got. All because some well-meaning people,
>> a few years in the past, thought that compilers "should".
>>
>>
>> > And besides, you can't test for all compiler bugs this way.
>>
>> Not all, but one can test for most everything that has to do with syntax.
>>
>>
>> On Sunday, July 26, 2015 at 7:17:41 PM UTC-6, Thiago Macieira wrote:
>>
>>> On Sunday 26 July 2015 18:03:16 denis bider wrote:
>>> > Maintaining that registry, now and forever in the future, does not
>>> seem
>>> > like a bureaucracy to you?
>>>
>>> Yes, it is. But it's something readily accessible now, which is more
>>> than any
>>> other alternatives.
>>>
>>> > It's extra work for language maintainers; it isn't general; and it
>>> doesn't
>>> > provide a way to test for differences in compiler implementations.
>>>
>>> True, but there shouldn't be differences in compiler implementations.
>>> Different
>>> revisions of a feature can be marked by different dates on the feature
>>> macro,
>>> such as __cpp_constexpr has done.
>>>
>>> Compiler bugs should be fixed. And besides, you can't test for all
>>> compiler
>>> bugs this way.
>>>
>>> > > Sentinel compilation would imply a major feature to the language.
>>> > > You can already do that with a configure script, if you want,
>>> though.
>>> >
>>> > That opens a whole other can of worms, which sentinel compilation
>>> would
>>> > make it easy to avoid.
>>>
>>> --
>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>> Software Architect - Intel Open Source Technology Center
>>> PGP/GPG: 0x6EF45358; fingerprint:
>>> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>>>
>>>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2487_997462932.1437965476328
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Sorry for the spam, but -</div><div><br></div><div>Wi=
th respect to this:</div><div><br></div><div>> > And besides, you can=
't test for all compiler=C2=A0bugs this way.</div><div>> Not all, bu=
t one can test for most everything that has to do with syntax.</div><div><b=
r></div><div>You can put a <em>static_assert</em> in the test block, too, a=
nd thereby test for anything that the compiler can evaluate at compile time=
;=C2=A0<em>including</em> whether the compiler can evaluate what you're=
testing, in the first place.</div><div><br><br>On Sunday, July 26, 2015 at=
8:43:43 PM UTC-6, denis bider wrote:</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color:=
rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><di=
v dir=3D"ltr"><div>Pardon me, I do have access to Clang, which implements t=
hat.</div><div><br></div><div>Of course, I don't actually use <em>Clang=
</em>... ;)</div><div>=C2=A0<br><br>On Sunday, July 26, 2015 at 8:36:07 PM =
UTC-6, denis bider wrote:</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 20=
4, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr=
"><div>It is not, in fact, readily accessible now. It is an inferior soluti=
on that has not yet been implemented by any compiler that I have access to.=
It will require maintenance for any new language features added, ever. Whe=
ther today, five years from now, 10 years from now - any new feature that i=
s added will have to be added to the registry. There will be problems when =
a feature is implemented this way by this compiler, that way by another. Th=
ere will be problems when a feature is considered part of another feature, =
but compiler implementers treat them separately.</div><div><br></div><div>&=
gt; True, but there shouldn't be differences in compiler implementation=
s.</div><div><br></div><div>There is a tremendous amount of hubris in this =
single word, "should". If you <em>had the power</em> to cause com=
piler implementations to be consistent, you wouldn't need this registry=
to begin with.</div><div><br></div><div>I'm betting that the reason pe=
r-feature macros were not specified earlier; so that we could use them=C2=
=A0now;=C2=A0was still more "should" reasoning, of the type you e=
spouse above. I'm betting that the standards body thought compilers &qu=
ot;should" implement each language version as a whole, instead of piec=
emeal. I'm betting they thought that adding per-feature macros, at that=
time, would have encouraged piecemeal implementation. They thought compile=
rs "should" implement a whole standard version at a time, and upd=
ate their __cplusplus macro value correspondingly.</div><div><br></div><div=
>Now, look at what we actually got. All because some well-meaning people, a=
few years in the past, thought that compilers "should".</div><di=
v><br></div><div><br></div><div>> And besides, you can't test for al=
l compiler=C2=A0bugs this way. </div><div><br></div><div>Not all, but one c=
an test for most everything that has to do with syntax.</div><div><br><br>O=
n Sunday, July 26, 2015 at 7:17:41 PM UTC-6, Thiago Macieira wrote:</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding=
-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; =
border-left-style: solid;">On Sunday 26 July 2015 18:03:16 denis bider wrot=
e:
<br>> Maintaining that registry, now and forever in the future, does not=
seem
<br>> like a bureaucracy to you?
<br>
<br>Yes, it is. But it's something readily accessible now, which is mor=
e than any=20
<br>other alternatives.
<br>
<br>> It's extra work for language maintainers; it isn't general=
; and it doesn't
<br>> provide a way to test for differences in compiler implementations.
<br>
<br>True, but there shouldn't be differences in compiler implementation=
s. Different=20
<br>revisions of a feature can be marked by different dates on the feature =
macro,=20
<br>such as __cpp_constexpr has done.
<br>
<br>Compiler bugs should be fixed. And besides, you can't test for all =
compiler=20
<br>bugs this way.
<br>
<br>> > Sentinel compilation would imply a major feature to the langu=
age.
<br>> > You can already do that with a configure script, if you want,=
though.
<br>>=20
<br>> That opens a whole other can of worms, which sentinel compilation =
would
<br>> make it easy to avoid.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.=
href=3D'http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;=
" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofollow">macieira=
..info</a> - thiago (AT) <a onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJd=
o5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http=
://www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" href=3D"http://kde.o=
rg" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div></blockquote></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2487_997462932.1437965476328--
------=_Part_2486_1244313517.1437965476328--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 26 Jul 2015 20:19:19 -0700
Raw View
On Sunday 26 July 2015 19:36:07 denis bider wrote:
> It is not, in fact, readily accessible now. It is an inferior solution that
> has not yet been implemented by any compiler that I have access to.
It's been in Clang since 3.5 (at least, I didn't check earlier), GCC 5 and
ICC 16. I don't think Microsoft added it to 2015, but they don't have much in
terms of C++14 yet, which is where this becomes more useful.
> It will
> require maintenance for any new language features added, ever. Whether
> today, five years from now, 10 years from now - any new feature that is
> added will have to be added to the registry. There will be problems when a
> feature is implemented this way by this compiler, that way by another.
> There will be problems when a feature is considered part of another
> feature, but compiler implementers treat them separately.
Aside from compatibility, you're right. The standard specifies how the feature
should work, so there should be no difference.
Different behaviour of a standard feature is a bug in the compiler or a defect
in the standard, neither of which anyone wants. Extension functionality can be
marked by their own ways.
> > True, but there shouldn't be differences in compiler implementations.
>
> There is a tremendous amount of hubris in this single word, "should". If
> you *had the power* to cause compiler implementations to be consistent, you
> wouldn't need this registry to begin with.
I still would, because none of the compilers suddenly implemented all of the
features. They came over the course of years, so in order to use partial
implementations, we still needed to check some kind of macro.
> I'm betting that the reason per-feature macros were not specified earlier;
> so that we could use them now; was still more "should" reasoning, of the
> type you espouse above. I'm betting that the standards body thought
> compilers "should" implement each language version as a whole, instead of
> piecemeal. I'm betting they thought that adding per-feature macros, at that
> time, would have encouraged piecemeal implementation. They thought
> compilers "should" implement a whole standard version at a time, and update
> their __cplusplus macro value correspondingly.
Correct, which is why SG10 SD6 was not part of C++11 and is optional to
implement. I was surprised to see it proposed as a paper.
But we've been doing macro checking for years. Getting standard macro names
goes a long way towards simplifying the checks.
> Now, look at what we actually got. All because some well-meaning people, a
> few years in the past, thought that compilers "should".
>
> > And besides, you can't test for all compiler bugs this way.
>
> Not all, but one can test for most everything that has to do with syntax.
And you'd still need a macro for everything else that is not a compiler bug.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 26 Jul 2015 20:21:19 -0700
Raw View
On Sunday 26 July 2015 19:51:16 denis bider wrote:
> > > And besides, you can't test for all compiler bugs this way.
> >
> > Not all, but one can test for most everything that has to do with syntax.
>
> You can put a *static_assert* in the test block, too, and thereby test for
> anything that the compiler can evaluate at compile time; *including*
> whether the compiler can evaluate what you're testing, in the first place.
Correct, but there's no static_if and in any case everything must still be
parsed properly. You can't use either feature to test for syntax the compiler
does not support.
I'm skeptical how much the compiler could recover in case of a syntax it does
not understand with your proposal.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Jim Porter <jvp4846@g.rit.edu>
Date: Sun, 26 Jul 2015 23:02:57 -0500
Raw View
On 7/26/2015 9:36 PM, denis bider wrote:
> It is not, in fact, readily accessible now. It is an inferior solution
> that has not yet been implemented by any compiler that I have access to.
Nor is your proposal; any new C++ feature of this sort would be unusable
if you need to compile on sufficiently-old compilers.
> > > Sentinel compilation would imply a major feature to the language.
> > > You can already do that with a configure script, if you want, though.
> >
> > That opens a whole other can of worms, which sentinel compilation would
> > make it easy to avoid.
Perhaps I'm just misunderstanding what you mean, but I'm not sure how a
build system that understands the tools it's using to build your
software is a "can of worms". Cross-platform build configuration already
has a long history of use in general-purpose build systems (autotools,
CMake, and many others support it). While you might not like autotools
or CMake, I'm sure you could find a build system that you don't mind
that lets you perform configuration-time compilation tests. This gives
you all the flexibility of your proposal (albeit with different syntax)
with the added benefit that you can even support C++98 compilers.
- Jim
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: denis bider <isocppgroup@denisbider.com>
Date: Sun, 26 Jul 2015 21:15:10 -0700 (PDT)
Raw View
------=_Part_2495_1560318121.1437970510266
Content-Type: multipart/alternative;
boundary="----=_Part_2496_1003193867.1437970510266"
------=_Part_2496_1003193867.1437970510266
Content-Type: text/plain; charset=UTF-8
Thiago:
> I'm skeptical how much the compiler could recover in case
> of a syntax it does not understand with your proposal.
If it cannot parse something within the block, it would note that as a test
block error (not a compilation error); skip the current line, and skip any
further lines until the first one that's a preprocessor directive.
The first line that's a preprocessor directive marks the end of the test
block.
Without further rules, this does mean a compiler that parses the test block
might be made to skip over a line which a compiler which cannot parse the
test block would interpret as the end of the test block. Trailing
backslashes and raw string literals are some ways this could be made to
happen, but I'm not sure that is really a problem.
Jim:
> Nor is your proposal; any new C++ feature of this sort
> would be unusable if you need to compile on
> sufficiently-old compilers.
Obviously. But once implemented, my proposal provides eternal,
general, universal feature testing support.
The registry approach, meanwhile, will be challenged and may fail in some
way for every new feature that is added.
> I'm sure you could find a build system that you don't mind
> that lets you perform configuration-time compilation tests
If I have control over the build system, I don't have the problem to begin
with. In that case, I can also choose the compiler, and I know what
features it implements and what it doesn't.
The problem mainly exists for libraries; especially cross-platform
libraries, and such a library can't rely on a single build system. Solving
this via build system just makes the problem bigger. Now instead of just
figuring out what the compiler supports, I have to figure out what build
system the user wants to use, and how to use that to figure out what the
compiler supports.
If you can force selection of the technology platform, *you don't have this
problem*.
On Sunday, July 26, 2015 at 9:21:23 PM UTC-6, Thiago Macieira wrote:
> On Sunday 26 July 2015 19:51:16 denis bider wrote:
> > > > And besides, you can't test for all compiler bugs this way.
> > >
> > > Not all, but one can test for most everything that has to do with
> syntax.
> >
> > You can put a *static_assert* in the test block, too, and thereby test
> for
> > anything that the compiler can evaluate at compile time; *including*
> > whether the compiler can evaluate what you're testing, in the first
> place.
>
> Correct, but there's no static_if and in any case everything must still be
> parsed properly. You can't use either feature to test for syntax the
> compiler
> does not support.
>
> I'm skeptical how much the compiler could recover in case of a syntax it
> does
> not understand with your proposal.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2496_1003193867.1437970510266
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Thiago:</div><div><br></div><div>> I'm skeptic=
al how much the compiler could recover in case</div><div>> of a syntax i=
t does not understand with your proposal. </div><div><br></div><div>If it c=
annot parse something within the block, it would note that as a test block =
error (not a compilation error); skip the current line, and skip any furthe=
r lines=C2=A0until the first one that's=C2=A0a preprocessor directive.<=
/div><div><br></div><div>The first line that's a preprocessor directive=
marks the end of the test block.</div><div><br></div><div>Without further =
rules, this does=C2=A0mean a compiler that parses the test block might be m=
ade to skip over a=C2=A0line which=C2=A0a compiler which cannot parse the t=
est block would interpret as the end of the test block. Trailing backslashe=
s and raw string literals are some ways this could be made to happen, but I=
'm not sure that is really a problem.</div><div><br></div><div><br></di=
v><div>Jim:</div><div><br></div><div>> Nor is your proposal; any new C++=
feature of this sort</div><div>> would be unusable if you need to compi=
le on</div><div>> sufficiently-old compilers. </div><div><br></div><div>=
Obviously. But once implemented, my proposal provides eternal, general,=C2=
=A0universal feature testing support.</div><div><br></div><div>The registry=
approach, meanwhile, will be challenged and may fail in some way for every=
new feature that is added.</div><div><br></div><div><br></div><div>> I&=
#39;m sure you could find a build system that you don't mind <br>> =
that lets you perform configuration-time compilation tests</div><div><br></=
div><div>If I have control over the build system, I don't have the prob=
lem to begin with. In that case, I can also choose the compiler, and I know=
what features it implements and what it doesn't.</div><div><br></div><=
div>The problem mainly exists for libraries; especially cross-platform libr=
aries, and such a library can't rely on a single build system. Solving =
this via build system just makes the problem bigger. Now instead of just fi=
guring out what the compiler supports, I have to figure out what build syst=
em the user wants to use, and how to use that to figure out what the compil=
er supports.</div><div><br></div><div>If you can force selection of the tec=
hnology platform, <em>you don't have this problem</em>.</div><div><br><=
br>On Sunday, July 26, 2015 at 9:21:23 PM UTC-6, Thiago Macieira wrote:</di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pad=
ding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1=
px; border-left-style: solid;">On Sunday 26 July 2015 19:51:16 denis bider =
wrote:
<br>> > > And besides, you can't test for all compiler bugs th=
is way.
<br>> >=20
<br>> > Not all, but one can test for most everything that has to do =
with syntax.
<br>>=20
<br>> You can put a *static_assert* in the test block, too, and thereby =
test for=20
<br>> anything that the compiler can evaluate at compile time; *includin=
g*=20
<br>> whether the compiler can evaluate what you're testing, in the =
first place.
<br>
<br>Correct, but there's no static_if and in any case everything must s=
till be=20
<br>parsed properly. You can't use either feature to test for syntax th=
e compiler=20
<br>does not support.
<br>
<br>I'm skeptical how much the compiler could recover in case of a synt=
ax it does=20
<br>not understand with your proposal.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.=
href=3D'http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;=
" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofollow">macieira=
..info</a> - thiago (AT) <a onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJd=
o5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http=
://www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" href=3D"http://kde.o=
rg" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2496_1003193867.1437970510266--
------=_Part_2495_1560318121.1437970510266--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 26 Jul 2015 21:35:13 -0700
Raw View
On Sunday 26 July 2015 21:15:10 denis bider wrote:
> Thiago:
> > I'm skeptical how much the compiler could recover in case
> > of a syntax it does not understand with your proposal.
>
> If it cannot parse something within the block, it would note that as a test
> block error (not a compilation error); skip the current line, and skip any
> further lines until the first one that's a preprocessor directive.
>
> The first line that's a preprocessor directive marks the end of the test
> block.
That sounds over-simplistic. What if the test requires the second phase of
template lookups? The compiler may not be ready to do that just yet, given its
architecture. For example, I don't trust GCC's -fsyntax-only option: in the
past, it would not find all syntax errors unless you actually compiled the
code.
What you're asking for is that the compiler copy its state, launch a new
process and treat the program as ending there, then report back. That might be
very costly in some operating systems -- if it's possible at all, as it the
compiler process might have grown very big already (ever tried compiling one
of WebKit/Blink's AllInOne.cpp files?).
So why not use a configure script? This has been done for 30 years and the
technology is proven. Not only that, this kind of tests can be done once for
many sources and they can detect link failures too. It might be more
inconvenient, but it's a superior solution.
> Obviously. But once implemented, my proposal provides eternal,
> general, universal feature testing support.
>
> The registry approach, meanwhile, will be challenged and may fail in some
> way for every new feature that is added.
Just as it would for people who write faulty tests.
> > I'm sure you could find a build system that you don't mind
> > that lets you perform configuration-time compilation tests
>
> If I have control over the build system, I don't have the problem to begin
> with. In that case, I can also choose the compiler, and I know what
> features it implements and what it doesn't.
Usually you can choose the buildsystem but not the compiler.
> The problem mainly exists for libraries; especially cross-platform
> libraries, and such a library can't rely on a single build system.
Sure it can. In fact, I don't know a single non-trivial library that allows
the user compiling it to choose the buildsystem. They come with one pre-
determined by the developers of that library.
> Solving
> this via build system just makes the problem bigger. Now instead of just
> figuring out what the compiler supports, I have to figure out what build
> system the user wants to use, and how to use that to figure out what the
> compiler supports.
Oh, I see what you mean. You mean detecting features at the time of compiling
the user's code.
That can easily be solved by removing the problem altogether. Determine the
features supported at the time of compiling the library itself and write a
config.h-like file (just don't call it "config.h"). The features supported at the
time you compiled the library will still be supported at the time the library
is used. Compiler downgrades are not possible for a lot of reasons, so this
would be the least of the problems.
The only issue would be sideways update, like switching from GCC to Clang or
to ICC or another permutation that generates binary-compatible output.
But in any case, we went back to #ifdef'ery, which is helped by having
standard macros so you don't have to write a config.h file.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: denis bider <isocppgroup@denisbider.com>
Date: Mon, 27 Jul 2015 15:24:59 -0700 (PDT)
Raw View
------=_Part_3521_2074053500.1438035899995
Content-Type: multipart/alternative;
boundary="----=_Part_3522_771965206.1438035899995"
------=_Part_3522_771965206.1438035899995
Content-Type: text/plain; charset=UTF-8
Yeah... You're right about the second phase of template lookups.
The easiest solution would seem to be to make the test/probe code
completely independent. This means the probe would have to run its own
#includes if it needs any, e.g. to test for features which require certain
headers. It means it would have to be encapsulated in some other kind of
syntax; perhaps in a C++ raw string literal.
Indeed; the compiler would then be expected to behave as if it launched a
child process of itself to compile that code, and report back on any
errors. If a compiler is well-architected - does not rely on global objects
and such to store state - it should be possible to do this without
launching a separate process.
I guess, if you are saying this is hard, you're saying many compilers are
poorly implemented? Use global state such that they can't create another
instance of the compiler in-process?
On Sunday, July 26, 2015 at 10:35:23 PM UTC-6, Thiago Macieira wrote:
> On Sunday 26 July 2015 21:15:10 denis bider wrote:
> > Thiago:
> > > I'm skeptical how much the compiler could recover in case
> > > of a syntax it does not understand with your proposal.
> >
> > If it cannot parse something within the block, it would note that as a
> test
> > block error (not a compilation error); skip the current line, and skip
> any
> > further lines until the first one that's a preprocessor directive.
> >
> > The first line that's a preprocessor directive marks the end of the test
> > block.
>
> That sounds over-simplistic. What if the test requires the second phase of
> template lookups? The compiler may not be ready to do that just yet, given
> its
> architecture. For example, I don't trust GCC's -fsyntax-only option: in
> the
> past, it would not find all syntax errors unless you actually compiled the
> code.
>
> What you're asking for is that the compiler copy its state, launch a new
> process and treat the program as ending there, then report back. That
> might be
> very costly in some operating systems -- if it's possible at all, as it
> the
> compiler process might have grown very big already (ever tried compiling
> one
> of WebKit/Blink's AllInOne.cpp files?).
>
> So why not use a configure script? This has been done for 30 years and the
> technology is proven. Not only that, this kind of tests can be done once
> for
> many sources and they can detect link failures too. It might be more
> inconvenient, but it's a superior solution.
>
> > Obviously. But once implemented, my proposal provides eternal,
> > general, universal feature testing support.
> >
> > The registry approach, meanwhile, will be challenged and may fail in
> some
> > way for every new feature that is added.
>
> Just as it would for people who write faulty tests.
>
> > > I'm sure you could find a build system that you don't mind
> > > that lets you perform configuration-time compilation tests
> >
> > If I have control over the build system, I don't have the problem to
> begin
> > with. In that case, I can also choose the compiler, and I know what
> > features it implements and what it doesn't.
>
> Usually you can choose the buildsystem but not the compiler.
>
> > The problem mainly exists for libraries; especially cross-platform
> > libraries, and such a library can't rely on a single build system.
>
> Sure it can. In fact, I don't know a single non-trivial library that
> allows
> the user compiling it to choose the buildsystem. They come with one pre-
> determined by the developers of that library.
>
> > Solving
> > this via build system just makes the problem bigger. Now instead of just
> > figuring out what the compiler supports, I have to figure out what build
> > system the user wants to use, and how to use that to figure out what the
> > compiler supports.
>
> Oh, I see what you mean. You mean detecting features at the time of
> compiling
> the user's code.
>
> That can easily be solved by removing the problem altogether. Determine
> the
> features supported at the time of compiling the library itself and write a
> config.h-like file (just don't call it "config.h"). The features supported
> at the
> time you compiled the library will still be supported at the time the
> library
> is used. Compiler downgrades are not possible for a lot of reasons, so
> this
> would be the least of the problems.
>
> The only issue would be sideways update, like switching from GCC to Clang
> or
> to ICC or another permutation that generates binary-compatible output.
>
> But in any case, we went back to #ifdef'ery, which is helped by having
> standard macros so you don't have to write a config.h file.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3522_771965206.1438035899995
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Yeah... You're right about the second phase of te=
mplate lookups.</div><div><br></div><div>The easiest solution would seem to=
be to make the test/probe code completely independent. This means the prob=
e would have to run its own #includes if it needs any, e.g. to test for fea=
tures which require certain headers. It means it would have to be encapsula=
ted in some other kind of syntax; perhaps in a C++ raw string literal.</div=
><div><br></div><div>Indeed;=C2=A0the compiler would then be expected to be=
have as if it launched a child process of itself to compile that code, and =
report back on any errors. If a compiler is well-architected - does not rel=
y on global objects and such to store state - it should be possible to do t=
his without launching a separate process.</div><div><br></div><div>I guess,=
if you are saying this is hard, you're saying many compilers are poorl=
y implemented? Use global state such that they can't create another ins=
tance of the compiler in-process?</div><div><br><br>On Sunday, July 26, 201=
5 at 10:35:23 PM UTC-6, Thiago Macieira wrote:</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-le=
ft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: so=
lid;">On Sunday 26 July 2015 21:15:10 denis bider wrote:
<br>> Thiago:
<br>> > I'm skeptical how much the compiler could recover in case
<br>> > of a syntax it does not understand with your proposal.
<br>>=20
<br>> If it cannot parse something within the block, it would note that =
as a test
<br>> block error (not a compilation error); skip the current line, and =
skip any
<br>> further lines until the first one that's a preprocessor direct=
ive.
<br>>=20
<br>> The first line that's a preprocessor directive marks the end o=
f the test
<br>> block.
<br>
<br>That sounds over-simplistic. What if the test requires the second phase=
of=20
<br>template lookups? The compiler may not be ready to do that just yet, gi=
ven its=20
<br>architecture. For example, I don't trust GCC's -fsyntax-only op=
tion: in the=20
<br>past, it would not find all syntax errors unless you actually compiled =
the=20
<br>code.
<br>
<br>What you're asking for is that the compiler copy its state, launch =
a new=20
<br>process and treat the program as ending there, then report back. That m=
ight be=20
<br>very costly in some operating systems -- if it's possible at all, a=
s it the=20
<br>compiler process might have grown very big already (ever tried compilin=
g one=20
<br>of WebKit/Blink's AllInOne.cpp files?).
<br>
<br>So why not use a configure script? This has been done for 30 years and =
the=20
<br>technology is proven. Not only that, this kind of tests can be done onc=
e for=20
<br>many sources and they can detect link failures too. It might be more=20
<br>inconvenient, but it's a superior solution.
<br>
<br>> Obviously. But once implemented, my proposal provides eternal,
<br>> general, universal feature testing support.
<br>>=20
<br>> The registry approach, meanwhile, will be challenged and may fail =
in some
<br>> way for every new feature that is added.
<br>
<br>Just as it would for people who write faulty tests.
<br>
<br>> > I'm sure you could find a build system that you don't=
mind
<br>> > that lets you perform configuration-time compilation tests
<br>>=20
<br>> If I have control over the build system, I don't have the prob=
lem to begin
<br>> with. In that case, I can also choose the compiler, and I know wha=
t
<br>> features it implements and what it doesn't.
<br>
<br>Usually you can choose the buildsystem but not the compiler.
<br>
<br>> The problem mainly exists for libraries; especially cross-platform
<br>> libraries, and such a library can't rely on a single build sys=
tem.
<br>
<br>Sure it can. In fact, I don't know a single non-trivial library tha=
t allows=20
<br>the user compiling it to choose the buildsystem. They come with one pre=
-
<br>determined by the developers of that library.
<br>
<br>> Solving
<br>> this via build system just makes the problem bigger. Now instead o=
f just
<br>> figuring out what the compiler supports, I have to figure out what=
build
<br>> system the user wants to use, and how to use that to figure out wh=
at the
<br>> compiler supports.
<br>
<br>Oh, I see what you mean. You mean detecting features at the time of com=
piling=20
<br>the user's code.
<br>
<br>That can easily be solved by removing the problem altogether. Determine=
the=20
<br>features supported at the time of compiling the library itself and writ=
e a=20
<br>config.h-like file (just don't call it "config.h"). The f=
eatures supported at the=20
<br>time you compiled the library will still be supported at the time the l=
ibrary=20
<br>is used. Compiler downgrades are not possible for a lot of reasons, so =
this=20
<br>would be the least of the problems.
<br>
<br>The only issue would be sideways update, like switching from GCC to Cla=
ng or=20
<br>to ICC or another permutation that generates binary-compatible output.
<br>
<br>But in any case, we went back to #ifdef'ery, which is helped by hav=
ing=20
<br>standard macros so you don't have to write a config.h file.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.=
href=3D'http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;=
" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofollow">macieira=
..info</a> - thiago (AT) <a onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJd=
o5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http=
://www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" href=3D"http://kde.o=
rg" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3522_771965206.1438035899995--
------=_Part_3521_2074053500.1438035899995--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 27 Jul 2015 16:09:12 -0700
Raw View
On Monday 27 July 2015 15:24:59 denis bider wrote:
> Indeed; the compiler would then be expected to behave as if it launched a
> child process of itself to compile that code, and report back on any
> errors. If a compiler is well-architected - does not rely on global objects
> and such to store state - it should be possible to do this without
> launching a separate process.
>
> I guess, if you are saying this is hard, you're saying many compilers are
> poorly implemented? Use global state such that they can't create another
> instance of the compiler in-process?
"Poorly implemented" is a subjective quality assessment, unless you make the
objective measurement of whether it does what it set out to do. Since those
compilers are working and are getting modified rapidly by their developer teams
to add features, we cannot honestly say that any of them is poorly
implemented, however we may feel about their architecture.
Some architectures may be welcoming of some new changes and some others
wouldn't. And if the committee approves a certain feature, the developers will
have to implement the functionality.
I was just warning that there might be quite a lot of resistance from the
compiler writers, given the architectural issues I mentioned, plus:
- there's already a solution for some of the use-cases presented, including
foremost the one you presented
- it does not go far enough to the very common case of linking a test program
to see if a function does exist in a library or the not-as-common case of
running a test program to see how it behaves.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Erich Keane <erich.keane@verizon.net>
Date: Tue, 28 Jul 2015 11:09:54 -0700 (PDT)
Raw View
------=_Part_161_337512148.1438106994243
Content-Type: multipart/alternative;
boundary="----=_Part_162_1193958586.1438106994243"
------=_Part_162_1193958586.1438106994243
Content-Type: text/plain; charset=UTF-8
On Monday, July 27, 2015 at 4:09:18 PM UTC-7, Thiago Macieira wrote:
>
> On Monday 27 July 2015 15:24:59 denis bider wrote:
> > Indeed; the compiler would then be expected to behave as if it launched
> a
> > child process of itself to compile that code, and report back on any
> > errors. If a compiler is well-architected - does not rely on global
> objects
> > and such to store state - it should be possible to do this without
> > launching a separate process.
> >
> > I guess, if you are saying this is hard, you're saying many compilers
> are
> > poorly implemented? Use global state such that they can't create another
> > instance of the compiler in-process?
>
> "Poorly implemented" is a subjective quality assessment, unless you make
> the
> objective measurement of whether it does what it set out to do. Since
> those
> compilers are working and are getting modified rapidly by their developer
> teams
> to add features, we cannot honestly say that any of them is poorly
> implemented, however we may feel about their architecture.
>
> Some architectures may be welcoming of some new changes and some others
> wouldn't. And if the committee approves a certain feature, the developers
> will
> have to implement the functionality.
>
> I was just warning that there might be quite a lot of resistance from the
> compiler writers, given the architectural issues I mentioned, plus:
> - there's already a solution for some of the use-cases presented,
> including
> foremost the one you presented
> - it does not go far enough to the very common case of linking a test
> program
> to see if a function does exist in a library or the not-as-common case
> of
> running a test program to see how it behaves.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
>
My concern is that we couldn't trust the compiler makers to properly set
these macros EVEN IF they were making their best effort. By definition,
they won't likely know if a feature is sufficiently bug free until it has
spent some time accruing bug reports.
I believe the 'best' solution would be to have a community maintained
include file to do this based on versions that everyone could pull into
their projects. A simple github file with these definitions based on the
major compilers, as long as it is sufficiently maintained, would do a lot
better than trusting that the compiler manufacturers release bug-free and
tag appropriately.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_162_1193958586.1438106994243
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, July 27, 2015 at 4:09:18 PM UTC-7, Thiago Macieira wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Monday 27 July 2015 15:24:59 denis=
bider wrote:
<br>> Indeed; the compiler would then be expected to behave as if it lau=
nched a
<br>> child process of itself to compile that code, and report back on a=
ny
<br>> errors. If a compiler is well-architected - does not rely on globa=
l objects
<br>> and such to store state - it should be possible to do this without
<br>> launching a separate process.
<br>>=20
<br>> I guess, if you are saying this is hard, you're saying many co=
mpilers are
<br>> poorly implemented? Use global state such that they can't crea=
te another
<br>> instance of the compiler in-process?
<br>
<br>"Poorly implemented" is a subjective quality assessment, unle=
ss you make the=20
<br>objective measurement of whether it does what it set out to do. Since t=
hose=20
<br>compilers are working and are getting modified rapidly by their develop=
er teams=20
<br>to add features, we cannot honestly say that any of them is poorly=20
<br>implemented, however we may feel about their architecture.
<br>
<br>Some architectures may be welcoming of some new changes and some others=
=20
<br>wouldn't. And if the committee approves a certain feature, the deve=
lopers will=20
<br>have to implement the functionality.
<br>
<br>I was just warning that there might be quite a lot of resistance from t=
he=20
<br>compiler writers, given the architectural issues I mentioned, plus:
<br>=C2=A0- there's already a solution for some of the use-cases presen=
ted, including=20
<br>=C2=A0 foremost the one you presented
<br>=C2=A0- it does not go far enough to the very common case of linking a =
test program=20
<br>=C2=A0 =C2=A0to see if a function does exist in a library or the not-as=
-common case of
<br>=C2=A0 =C2=A0running a test program to see how it behaves.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D&=
#39;http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46snt=
z\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">maciei=
ra.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\7=
5http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1Dowztw=
AHAKs80XSA';return true;" onclick=3D"this.href=3D'http://www.google=
..com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo=
5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote><div><br>My concern is that we couldn't trust the comp=
iler makers to properly set these macros EVEN IF they were making their bes=
t effort.=C2=A0 By definition, they won't likely know if a feature is s=
ufficiently bug free until it has spent some time accruing bug reports.<br>=
<br>I believe the 'best' solution would be to have a community main=
tained include file to do this based on versions that everyone could pull i=
nto their projects.=C2=A0 A simple github file with these definitions based=
on the major compilers, as long as it is sufficiently maintained, would do=
a lot better than trusting that the compiler manufacturers release bug-fre=
e and tag appropriately.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_162_1193958586.1438106994243--
------=_Part_161_337512148.1438106994243--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 28 Jul 2015 11:18:58 -0700
Raw View
On Tuesday 28 July 2015 11:09:54 Erich Keane wrote:
> My concern is that we couldn't trust the compiler makers to properly set
> these macros EVEN IF they were making their best effort. By definition,
> they won't likely know if a feature is sufficiently bug free until it has
> spent some time accruing bug reports.
>
> I believe the 'best' solution would be to have a community maintained
> include file to do this based on versions that everyone could pull into
> their projects. A simple github file with these definitions based on the
> major compilers, as long as it is sufficiently maintained, would do a lot
> better than trusting that the compiler manufacturers release bug-free and
> tag appropriately.
Erich has a point and I can actually attest to that. If you look at Qt's
qcompilerdetection.h file, you'll see quite a few places where the Qt C++11
feature macros disagree with the official tables from the compiler vendors
because the feature is either broken or incomplete.
The most common cases are when one mixes the compiler from one vendor with the
Standard Library from another. Even modern and recent libraries like libc++
have faults there because they aren't often tested with other compilers
besides the one from the same vendor.
So, yeah, maybe we should keep a central list outside of the compiler so that
it can be updated to indicate compiler bugs.
We'll just have to squabble over a bug is really worth disabling a feature.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Erich Keane <erich.keane@verizon.net>
Date: Tue, 28 Jul 2015 14:15:39 -0700 (PDT)
Raw View
------=_Part_4906_799861443.1438118139956
Content-Type: multipart/alternative;
boundary="----=_Part_4907_1984553317.1438118139957"
------=_Part_4907_1984553317.1438118139957
Content-Type: text/plain; charset=UTF-8
On Tuesday, July 28, 2015 at 11:19:03 AM UTC-7, Thiago Macieira wrote:
>
> On Tuesday 28 July 2015 11:09:54 Erich Keane wrote:
> > My concern is that we couldn't trust the compiler makers to properly set
> > these macros EVEN IF they were making their best effort. By definition,
> > they won't likely know if a feature is sufficiently bug free until it
> has
> > spent some time accruing bug reports.
> >
> > I believe the 'best' solution would be to have a community maintained
> > include file to do this based on versions that everyone could pull into
> > their projects. A simple github file with these definitions based on
> the
> > major compilers, as long as it is sufficiently maintained, would do a
> lot
> > better than trusting that the compiler manufacturers release bug-free
> and
> > tag appropriately.
>
> Erich has a point and I can actually attest to that. If you look at Qt's
> qcompilerdetection.h file, you'll see quite a few places where the Qt
> C++11
> feature macros disagree with the official tables from the compiler vendors
> because the feature is either broken or incomplete.
>
> The most common cases are when one mixes the compiler from one vendor with
> the
> Standard Library from another. Even modern and recent libraries like
> libc++
> have faults there because they aren't often tested with other compilers
> besides the one from the same vendor.
>
> So, yeah, maybe we should keep a central list outside of the compiler so
> that
> it can be updated to indicate compiler bugs.
>
> We'll just have to squabble over a bug is really worth disabling a
> feature.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
>
I'd imagine that boost has a similar file. Perhaps someone needs to just
implement the macros defined in 4440 in a github somewhere as a
cross-product of the Qt and boost (and whichever other major projects have
something like this!) as a starting piont.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_4907_1984553317.1438118139957
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, July 28, 2015 at 11:19:03 AM UTC-7, Thiago Macieira wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On Tuesday 28 July 2015 11:09:54 Er=
ich Keane wrote:
<br>> My concern is that we couldn't trust the compiler makers to pr=
operly set
<br>> these macros EVEN IF they were making their best effort. =C2=A0By =
definition,
<br>> they won't likely know if a feature is sufficiently bug free u=
ntil it has
<br>> spent some time accruing bug reports.
<br>>=20
<br>> I believe the 'best' solution would be to have a community=
maintained
<br>> include file to do this based on versions that everyone could pull=
into
<br>> their projects. =C2=A0A simple github file with these definitions =
based on the
<br>> major compilers, as long as it is sufficiently maintained, would d=
o a lot
<br>> better than trusting that the compiler manufacturers release bug-f=
ree and
<br>> tag appropriately.
<br>
<br>Erich has a point and I can actually attest to that. If you look at Qt&=
#39;s=20
<br>qcompilerdetection.h file, you'll see quite a few places where the =
Qt C++11=20
<br>feature macros disagree with the official tables from the compiler vend=
ors=20
<br>because the feature is either broken or incomplete.
<br>
<br>The most common cases are when one mixes the compiler from one vendor w=
ith the=20
<br>Standard Library from another. Even modern and recent libraries like li=
bc++=20
<br>have faults there because they aren't often tested with other compi=
lers=20
<br>besides the one from the same vendor.
<br>
<br>So, yeah, maybe we should keep a central list outside of the compiler s=
o that=20
<br>it can be updated to indicate compiler bugs.
<br>
<br>We'll just have to squabble over a bug is really worth disabling a =
feature.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D&=
#39;http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46snt=
z\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">maciei=
ra.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\7=
5http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1Dowztw=
AHAKs80XSA';return true;" onclick=3D"this.href=3D'http://www.google=
..com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo=
5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote><div><br><br>I'd imagine that boost has a similar file=
..=C2=A0 Perhaps someone needs to just implement the macros defined in 4440 =
in a github somewhere as a cross-product of the Qt and boost (and whichever=
other major projects have something like this!) as a starting piont.<br></=
div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4907_1984553317.1438118139957--
------=_Part_4906_799861443.1438118139956--
.
Author: denis bider <isocppgroup@denisbider.com>
Date: Tue, 28 Jul 2015 17:35:24 -0700 (PDT)
Raw View
------=_Part_1177_751417976.1438130124964
Content-Type: multipart/alternative;
boundary="----=_Part_1178_819334367.1438130124964"
------=_Part_1178_819334367.1438130124964
Content-Type: text/plain; charset=UTF-8
But if you had probe compilation, you could determine whether the
compiler's and the standard library's actual, exact level of support is
suitable for your actual, exact purposes.
Just saying... ;)
On Tuesday, July 28, 2015 at 12:19:03 PM UTC-6, Thiago Macieira wrote:
> On Tuesday 28 July 2015 11:09:54 Erich Keane wrote:
> > My concern is that we couldn't trust the compiler makers to properly set
> > these macros EVEN IF they were making their best effort. By definition,
> > they won't likely know if a feature is sufficiently bug free until it
> has
> > spent some time accruing bug reports.
> >
> > I believe the 'best' solution would be to have a community maintained
> > include file to do this based on versions that everyone could pull into
> > their projects. A simple github file with these definitions based on
> the
> > major compilers, as long as it is sufficiently maintained, would do a
> lot
> > better than trusting that the compiler manufacturers release bug-free
> and
> > tag appropriately.
>
> Erich has a point and I can actually attest to that. If you look at Qt's
> qcompilerdetection.h file, you'll see quite a few places where the Qt
> C++11
> feature macros disagree with the official tables from the compiler vendors
> because the feature is either broken or incomplete.
>
> The most common cases are when one mixes the compiler from one vendor with
> the
> Standard Library from another. Even modern and recent libraries like
> libc++
> have faults there because they aren't often tested with other compilers
> besides the one from the same vendor.
>
> So, yeah, maybe we should keep a central list outside of the compiler so
> that
> it can be updated to indicate compiler bugs.
>
> We'll just have to squabble over a bug is really worth disabling a
> feature.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1178_819334367.1438130124964
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>But if you had probe compilation, you could determine=
whether the compiler's and the standard=C2=A0library's actual, exa=
ct level of support is suitable for your actual, exact purposes.</div><div>=
<br></div><div>Just saying... ;)</div><div><br><br>On Tuesday, July 28, 201=
5 at 12:19:03 PM UTC-6, Thiago Macieira wrote:</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-le=
ft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: so=
lid;">On Tuesday 28 July 2015 11:09:54 Erich Keane wrote:
<br>> My concern is that we couldn't trust the compiler makers to pr=
operly set
<br>> these macros EVEN IF they were making their best effort. =C2=A0By =
definition,
<br>> they won't likely know if a feature is sufficiently bug free u=
ntil it has
<br>> spent some time accruing bug reports.
<br>>=20
<br>> I believe the 'best' solution would be to have a community=
maintained
<br>> include file to do this based on versions that everyone could pull=
into
<br>> their projects. =C2=A0A simple github file with these definitions =
based on the
<br>> major compilers, as long as it is sufficiently maintained, would d=
o a lot
<br>> better than trusting that the compiler manufacturers release bug-f=
ree and
<br>> tag appropriately.
<br>
<br>Erich has a point and I can actually attest to that. If you look at Qt&=
#39;s=20
<br>qcompilerdetection.h file, you'll see quite a few places where the =
Qt C++11=20
<br>feature macros disagree with the official tables from the compiler vend=
ors=20
<br>because the feature is either broken or incomplete.
<br>
<br>The most common cases are when one mixes the compiler from one vendor w=
ith the=20
<br>Standard Library from another. Even modern and recent libraries like li=
bc++=20
<br>have faults there because they aren't often tested with other compi=
lers=20
<br>besides the one from the same vendor.
<br>
<br>So, yeah, maybe we should keep a central list outside of the compiler s=
o that=20
<br>it can be updated to indicate compiler bugs.
<br>
<br>We'll just have to squabble over a bug is really worth disabling a =
feature.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.=
href=3D'http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;=
" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofollow">macieira=
..info</a> - thiago (AT) <a onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJd=
o5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http=
://www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" href=3D"http://kde.o=
rg" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1178_819334367.1438130124964--
------=_Part_1177_751417976.1438130124964--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 28 Jul 2015 17:42:33 -0700
Raw View
On Tuesday 28 July 2015 17:35:24 denis bider wrote:
> But if you had probe compilation, you could determine whether the compiler's
> and the standard library's actual, exact level of support is suitable for
> your actual, exact purposes.
>
> Just saying... ;)
Save for actually linking the code to see if the library contains the
functions it claims to have.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 29 Jul 2015 15:26:19 -0400
Raw View
On 2015-07-27 00:15, denis bider wrote:
> On 2015-07-26 23:21, Thiago Macieira wrote:
>> I'm skeptical how much the compiler could recover in case
>> of a syntax it does not understand with your proposal.
>
> If it cannot parse something within the block, it would note that as a test
> block error (not a compilation error); skip the current line, and skip any
> further lines until the first one that's a preprocessor directive.
>
> The first line that's a preprocessor directive marks the end of the test
> block.
You do realize that by the time the compiler sees the code, the PP has
already run?
You would need something other than PP markup to denote the beginning
and end of feature-test blocks.
TBH I think the idea is interesting, but I just don't see how it would
ever work except to have the compiler interrupt compiling, spin up a
separate "process" (not necessarily in the POSIX sense) to attempt to
compile some external, self-contained hunk of code, and act on the
result. The problem there is that the standard has strongly resisted
specifying anything about how the compiler interacts with the system,
i.e. anything beyond it consuming text from an input stream. Ergo I
think you would have a serious uphill battle to get such a feature
accepted. (Similarly, there is a lot of resistance to any PP changes.)
> If I have control over the build system, I don't have the problem to begin
> with. In that case, I can also choose the compiler, and I know what
> features it implements and what it doesn't.
>
> The problem mainly exists for libraries; especially cross-platform
> libraries, and such a library can't rely on a single build system.
I take it you are talking about the case of your library headers being
used by some consumer? Is that even *wise* to be changing your build
configuration at that point? In my experience, it's more typical that
users are required to use a compiler at least as capable as the one used
to build the library, and the library hard-codes what features were
enabled when it was built. (Some may even attempt to force matching
compiler abilities.)
Incidentally, CMake-based projects certainly encourage consumers to also
use CMake :-). (And CMake has feature tests. You can even arrange for
requests to use your library - i.e. by the consumer's build - to re-run
feature tests in the consumer's environment and propagate the results to
anyone using your library.)
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: denis bider <isocppgroup@denisbider.com>
Date: Wed, 29 Jul 2015 15:02:12 -0700 (PDT)
Raw View
------=_Part_1030_282930463.1438207332388
Content-Type: multipart/alternative;
boundary="----=_Part_1031_1318270355.1438207332389"
------=_Part_1031_1318270355.1438207332389
Content-Type: text/plain; charset=UTF-8
Thiago:
> Save for actually linking the code to see if the library
> contains the functions it claims to have.
I agree. However, I don't see this as a problem for the library performing
the test for features.
The library's job is to compile cleanly, and to produce object files that
can be used by the library user for further linkage. I would argue, if the
final program fails to link properly, that's the user's problem, not the
library's.
Definitions in header files are promises of the user of what's available,
via the compiler, to the library. It's up to the user to fulfill those
promises at the point of linkage.
If functions are missing - the user could define them (depending on how
involved they are).
Matthew:
> You do realize that by the time the compiler sees the code,
> the PP has already run?
I thought actual implementation has already migrated away from this
concept? I thought this is now more so a fiction that's no longer true in
practice.
For example, for MSVC to implement #pragma warning, it has to be performing
*some* type of meta-processing at the same time as compiling. Even if this
means running the preprocessor first, and inserting another kind of
meta-information that is processed at the same time as compiling.
Maybe other compilers do not do this, and adhere strictly to running the
preprocessor in a separate run?
Even so - the *preprocessor* could invoke the compiler. This should be easy
if the probe code is independent of what comes before and after.
Making the probe code completely independent is a departure from my
original suggestion. However, I have already conceded the need for this, so
that any template code that's part of the probe can be properly and fully
evaluated.
> In my experience, it's more typical that users are required
> to use a compiler at least as capable as the one used
> to build the library, and the library hard-codes what
> features were enabled when it was built.
Crypto++ would like to use e.g. move semantics without preventing use with
VS 2005. My understanding is that Boost also desires to use the latest
language features, but still provide compatibility with compilers that lack
them (if I'm not mistaken, including VS 2005?).
On Tuesday, July 28, 2015 at 6:42:40 PM UTC-6, Thiago Macieira wrote:
> On Tuesday 28 July 2015 17:35:24 denis bider wrote:
> > But if you had probe compilation, you could determine whether the
> compiler's
> > and the standard library's actual, exact level of support is suitable
> for
> > your actual, exact purposes.
> >
> > Just saying... ;)
>
> Save for actually linking the code to see if the library contains the
> functions it claims to have.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1031_1318270355.1438207332389
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Thiago:<br><br></div><div>> Save for actually link=
ing the code to see if the library</div><div>> contains the=C2=A0functio=
ns it claims to have. <br></div><div><br></div><div>I agree. However, I don=
't see this as=C2=A0a problem for the library performing the test for f=
eatures.</div><div><br></div><div>The library's job is to compile clean=
ly, and to produce object files that can be used by the library user for fu=
rther linkage. I would argue, if the final program fails to link properly, =
that's the user's problem, not the library's.</div><div><br></d=
iv><div>Definitions in header files are promises of the user of what's =
available, via the compiler, to the library. It's up to the user to ful=
fill those promises at the point of linkage.</div><div><br></div><div>If fu=
nctions are missing - the user could define them (depending on how involved=
they are).</div><div><br></div><div><br></div><div>Matthew:</div><div><br>=
</div><div>> You do realize that by the time the compiler sees the code,=
</div><div>> the PP has already run? <br></div><div><br></div><div>I tho=
ught actual implementation has already migrated away from this concept? I t=
hought this is now more so a fiction that's no longer true in practice.=
</div><div><br></div><div>For example, for MSVC to implement #pragma warnin=
g, it has to be performing <em>some</em> type of meta-processing at the sam=
e time as compiling. Even if this means running the preprocessor first, and=
inserting another kind of meta-information that is processed at the same t=
ime as compiling.</div><div><br></div><div>Maybe other compilers do not do =
this, and adhere strictly to running the preprocessor in a separate run?</d=
iv><div><br></div><div>Even so -=C2=A0the <em>preprocessor</em> could invok=
e the compiler.=C2=A0This should be easy if the probe code is independent o=
f=C2=A0what comes before and after.</div><div><br></div><div>Making the pro=
be code completely independent=C2=A0is a departure from my original suggest=
ion. However,=C2=A0I=C2=A0have already conceded the need for this,=C2=A0so =
that any template code=C2=A0that's part of the probe can be properly an=
d fully evaluated.</div><div><br></div><div><br></div><div>> In my exper=
ience, it's more typical that users are required</div><div>> to use =
a compiler at least as capable as the one used</div><div>> to build the =
library, and the library hard-codes what</div><div>> features were enabl=
ed when it was built.</div><div><br></div><div>Crypto++ would like to use e=
..g. move semantics without preventing use with VS 2005. My understanding is=
that Boost also desires to use the latest language features, but still pro=
vide compatibility with compilers that lack them (if I'm not mistaken, =
including=C2=A0VS 2005?).</div><div><br></div><div><br><br>On Tuesday, July=
28, 2015 at 6:42:40 PM UTC-6, Thiago Macieira wrote:</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bo=
rder-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-st=
yle: solid;">On Tuesday 28 July 2015 17:35:24 denis bider wrote:
<br>> But if you had probe compilation, you could determine whether the =
compiler's
<br>> and the standard library's actual, exact level of support is s=
uitable for
<br>> your actual, exact purposes.
<br>>=20
<br>> Just saying... ;)
<br>
<br>Save for actually linking the code to see if the library contains the=
=20
<br>functions it claims to have.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.=
href=3D'http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;=
" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofollow">macieira=
..info</a> - thiago (AT) <a onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJd=
o5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http=
://www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" href=3D"http://kde.o=
rg" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1031_1318270355.1438207332389--
------=_Part_1030_282930463.1438207332388--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 29 Jul 2015 17:55:26 -0700
Raw View
On Wednesday 29 July 2015 15:02:12 denis bider wrote:
> Thiago:
> > Save for actually linking the code to see if the library
> > contains the functions it claims to have.
>
> I agree. However, I don't see this as a problem for the library performing
> the test for features.
>
> The library's job is to compile cleanly, and to produce object files that
> can be used by the library user for further linkage. I would argue, if the
> final program fails to link properly, that's the user's problem, not the
> library's.
>
> Definitions in header files are promises of the user of what's available,
> via the compiler, to the library. It's up to the user to fulfill those
> promises at the point of linkage.
That sidesteps the issue of enabling and disabling features at compilation
time. For example, zlib.h might be available as a header
(__has_include(<zlib.h> is true), but -lz is not being passed to the linker.
That means a detection by the compiler may make matters worse.
Note also how I talked about a feature that is already being implemented. My
point is that those things do not replace a good configure script.
> Matthew:
> > You do realize that by the time the compiler sees the code,
> > the PP has already run?
>
> I thought actual implementation has already migrated away from this
> concept? I thought this is now more so a fiction that's no longer true in
> practice.
The compilers are required to produce preprocessed output, at least until
Modules comes along. I can still pass -E to the compiler and see the output.
> For example, for MSVC to implement #pragma warning, it has to be performing
> *some* type of meta-processing at the same time as compiling. Even if this
> means running the preprocessor first, and inserting another kind of
> meta-information that is processed at the same time as compiling.
#pragma is not a preprocessor token. That means this kind of compilation
detection, if accepted, could be something else, other than a preprocessor
directive. For example
#probe
code
#then
code
#else
code
#endprobe
Note how you could not #define inside the then and else clauses because the
preprocessor has already run. I wouldn't choose this method.
> Even so - the *preprocessor* could invoke the compiler. This should be easy
> if the probe code is independent of what comes before and after.
That's how I'd do it: the preprocessor should realise that running the
compiler is required and would launch it, getting the status.
That gets into a lot of hairy problems of how the preprocessor can run the
compiler. One of the ways of offloading code generation is to run the
preprocessor in one machine and send the preprocessed output to another to
compile. That means the preprocessor and the actual compiler may not exist in
both machines...
> > In my experience, it's more typical that users are required
> > to use a compiler at least as capable as the one used
> > to build the library, and the library hard-codes what
> > features were enabled when it was built.
>
> Crypto++ would like to use e.g. move semantics without preventing use with
> VS 2005. My understanding is that Boost also desires to use the latest
> language features, but still provide compatibility with compilers that lack
> them (if I'm not mistaken, including VS 2005?).
I don't think you understood my point.
I was saying that you can do a check of feature at the time of the compilation
of the library and record that in a config.h that gets installed with it, as
downgrading the compiler is a rare occurrence.
How often do you compile the library with VS 2010 (which supports move
semantics) and then compile the application with VS 2005? Answer: never.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 30 Jul 2015 11:14:21 -0400
Raw View
On 2015-07-29 18:02, denis bider wrote:
> On 2015-07-29 15:26, Matthew Woehlke wrote:
>> You do realize that by the time the compiler sees the code,
>> the PP has already run?
>
> I thought actual implementation has already migrated away from this
> concept? I thought this is now more so a fiction that's no longer true in
> practice.
I wouldn't count on that, especially if you're using ccache. As I
understand it, ccache works by running the PP and comparing the output
hash and compile flags against its cache of previously-built objects. I
don't actually know if, when it needs to compile something, it passes
the original input to the compiler as opposed to the
already-preprocessed input.
Hmm... that said, you might be right in the sense that IIRC there are
"PP" directives that are left in place (e.g. #pragma), or even added
(e.g. #line). So maybe my previous comment doesn't apply. Disregard,
then :-).
> Even so - the *preprocessor* could invoke the compiler. This should be easy
> if the probe code is independent of what comes before and after.
This could work. It may even be preferable (for one, if it worked this
way, it wouldn't break ccache if the result of the test changes).
However, making changes to the PP has historically met with a lot of
resistance.
>> In my experience, it's more typical that users are required
>> to use a compiler at least as capable as the one used
>> to build the library, and the library hard-codes what
>> features were enabled when it was built.
>
> Crypto++ would like to use e.g. move semantics without preventing use with
> VS 2005. My understanding is that Boost also desires to use the latest
> language features, but still provide compatibility with compilers that lack
> them (if I'm not mistaken, including VS 2005?).
*BUT*, do you mean that the library supports being compiled on an old
compiler? (That's fairly usual.) Or that the library supports being
built itself with a modern compiler and then used from an application
built with an old compiler? That may be possible, if you're very
careful, but you risk breakages due to the library having a different
notion than the application of what features are available.
On 2015-07-29 20:55, Thiago Macieira wrote:
> How often do you compile the library with VS 2010 (which supports move
> semantics) and then compile the application with VS 2005? Answer: never.
You could be using a pre-built library that was built with a newer
compiler to build an application on a machine that has only an older
compiler. (Although, pre-built stuff tends to use the oldest compiler
possible, or be available built with multiple compiler versions.)
It *can* happen, but the library headers may well check for that and
raise an error.
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 30 Jul 2015 09:02:46 -0700
Raw View
On Thursday 30 July 2015 11:14:21 Matthew Woehlke wrote:
> Hmm... that said, you might be right in the sense that IIRC there are
> "PP" directives that are left in place (e.g. #pragma), or even added
> (e.g. #line). So maybe my previous comment doesn't apply. Disregard,
> then :-).
The problem with that is that the compiler now sees the invalid code too and
needs to decide what (not) to do with it. You can't use the preprocessor to
remove code the compiler shouldn't see.
> On 2015-07-29 20:55, Thiago Macieira wrote:
> > How often do you compile the library with VS 2010 (which supports move
> > semantics) and then compile the application with VS 2005? Answer: never.
>
> You could be using a pre-built library that was built with a newer
> compiler to build an application on a machine that has only an older
> compiler. (Although, pre-built stuff tends to use the oldest compiler
> possible, or be available built with multiple compiler versions.)
You cannot do that. Let's forget the fact that MSVC versions are incompatible
with each other altogether and analyse the more common case of Unix shared
libraries:
The rule of thumb on shared libraries on Unix systems is that you must run
with a version equal to or higher than the one you linked to. Breaking that
rule is not supported by anyone.
> It *can* happen, but the library headers may well check for that and
> raise an error.
What headers? The problem is linking and dynamic linking.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 30 Jul 2015 12:31:41 -0400
Raw View
On 2015-07-30 12:02, Thiago Macieira wrote:
> On Thursday 30 July 2015 11:14:21 Matthew Woehlke wrote:
>> Hmm... that said, you might be right in the sense that IIRC there are
>> "PP" directives that are left in place (e.g. #pragma), or even added
>> (e.g. #line). So maybe my previous comment doesn't apply. Disregard,
>> then :-).
>
> The problem with that is that the compiler now sees the invalid code too and
> needs to decide what (not) to do with it. You can't use the preprocessor to
> remove code the compiler shouldn't see.
I must misunderstand something. If the test is done by the PP, then the
PP will remove the test code. (The PP most certainly can and does do
this sort of thing; see almost any use of '#if[def]'.)
If the test is *not* done by the PP, then the directives marking the
block would still be present, no? So the compiler can still isolate it
(and needs to do so anyway in order to perform the test).
Did I miss something?
>> On 2015-07-29 20:55, Thiago Macieira wrote:
>>> How often do you compile the library with VS 2010 (which supports move
>>> semantics) and then compile the application with VS 2005? Answer: never.
>>
>> You could be using a pre-built library that was built with a newer
>> compiler to build an application on a machine that has only an older
>> compiler. (Although, pre-built stuff tends to use the oldest compiler
>> possible, or be available built with multiple compiler versions.)
>
> You cannot do that. Let's forget the fact that MSVC versions are incompatible
> with each other altogether and analyse the more common case of Unix shared
> libraries:
>
> The rule of thumb on shared libraries on Unix systems is that you must run
> with a version equal to or higher than the one you linked to. Breaking that
> rule is not supported by anyone.
Well, yes, but that's essentially the point I was trying to make. What I
mean is, I can conceive of how someone might attempt to do such a thing,
but it's unlikely (maybe "unlikely" is even an understatement) that the
library would try to support it.
>> It *can* happen, but the library headers may well check for that and
>> raise an error.
>
> What headers? The problem is linking and dynamic linking.
I have at least once written a header that injects compiler information
into its "config.h" such that when you go to use the library, it checks
that the compiler you are using as a consumer is at least "as good as"
(for whatever metric, e.g. version, language version, etc.) what it was
built with, and raises an error otherwise.
I know Qt has some similar version checks. (Isn't MOC generated code set
up to refuse to build against older Qt headers than the version of MOC
that generated the code? In fact I want to say it's not even "older" but
"different"...)
(Here following points Thiago and I agree upon...)
At any rate, it's common to have checks of this nature, whether at
compile time, link time, or run time (e.g. using older Qt or libpng
library when built against newer headers, just to name two offhand
examples I *know* I've run into).
The upshot of this all being of course that there isn't as strong a
motivation to do feature checks at consumer-build time as library-build
time. And we can already do the latter.
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 30 Jul 2015 13:29:17 -0700
Raw View
On Thursday 30 July 2015 12:31:41 Matthew Woehlke wrote:
> On 2015-07-30 12:02, Thiago Macieira wrote:
> > On Thursday 30 July 2015 11:14:21 Matthew Woehlke wrote:
> >> Hmm... that said, you might be right in the sense that IIRC there are
> >> "PP" directives that are left in place (e.g. #pragma), or even added
> >> (e.g. #line). So maybe my previous comment doesn't apply. Disregard,
> >> then :-).
> >
> > The problem with that is that the compiler now sees the invalid code too
> > and needs to decide what (not) to do with it. You can't use the
> > preprocessor to remove code the compiler shouldn't see.
>
> I must misunderstand something. If the test is done by the PP, then the
> PP will remove the test code. (The PP most certainly can and does do
> this sort of thing; see almost any use of '#if[def]'.)
Correct, but that wasn't what was suggested. It was:
> If the test is *not* done by the PP, then the directives marking the
> block would still be present, no? So the compiler can still isolate it
> (and needs to do so anyway in order to perform the test).
>
> Did I miss something?
Just the part that the compiler usually does not deal with invalid code.
Invalid code is often removed by the preprocessor.
This requires moving a portion of the preprocessor's functionality into the
compiler itself.
> > You cannot do that. Let's forget the fact that MSVC versions are
> > incompatible with each other altogether and analyse the more common case
> > of Unix shared libraries:
> >
> > The rule of thumb on shared libraries on Unix systems is that you must run
> > with a version equal to or higher than the one you linked to. Breaking
> > that
> > rule is not supported by anyone.
>
> Well, yes, but that's essentially the point I was trying to make. What I
> mean is, I can conceive of how someone might attempt to do such a thing,
> but it's unlikely (maybe "unlikely" is even an understatement) that the
> library would try to support it.
Anyone who does that has special rules for how to deal with the issue. For
example, Qt is both forwards- and backwards-compatible within one minor
release. That implies we can't add any new symbols to the build. As a
consequence, there can be no new features.
The same is true here of a compiler feature: if a compiler begins supporting
move semantics, it's not forwards-compatible. No one will try to support this
because it doesn't work, period.
> >> It *can* happen, but the library headers may well check for that and
> >> raise an error.
> >
> > What headers? The problem is linking and dynamic linking.
>
> I have at least once written a header that injects compiler information
> into its "config.h" such that when you go to use the library, it checks
> that the compiler you are using as a consumer is at least "as good as"
> (for whatever metric, e.g. version, language version, etc.) what it was
> built with, and raises an error otherwise.
Indeed, but most people simply write code that implies this.
> I know Qt has some similar version checks. (Isn't MOC generated code set
> up to refuse to build against older Qt headers than the version of MOC
> that generated the code? In fact I want to say it's not even "older" but
> "different"...)
Right, but you don't deploy MOC-generated code. You're supposed to compile it
right now and then, so the Qt headers and the moc tool must match.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.