220 19296 <255fd5fb-cf04-431f-a576-d30926b86674@isocpp.org> article Path: news.gmane.org!not-for-mail From: denis bider Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Testing for supported features: Per-feature macros? Sentinel compilation? Date: Sun, 26 Jul 2015 19:51:16 -0700 (PDT) Lines: 232 Approved: news@gmane.org Message-ID: <255fd5fb-cf04-431f-a576-d30926b86674@isocpp.org> References: <1720943.XpK8Tt98Hf@tjmaciei-mobl4> <4897684.zJq850IzGK@tjmaciei-mobl4> <2a1df8fc-7d85-4c27-a8c7-102791d2fcf6@isocpp.org> <47831edb-dbc1-413e-9886-95e357c3bf20@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2486_1244313517.1437965476328" X-Trace: ger.gmane.org 1437965500 23882 80.91.229.3 (27 Jul 2015 02:51:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2015 02:51:40 +0000 (UTC) Cc: thiago@macieira.org, isocppgroup@denisbider.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBJNZ22WQKGQEUAGLYQY@isocpp.org Mon Jul 27 04:51:25 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f198.google.com ([209.85.213.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZJYVg-0001N4-4K for gclcip-std-proposals@m.gmane.org; Mon, 27 Jul 2015 04:51:24 +0200 Original-Received: by igr7 with SMTP id 7sf132077536igr.2 for ; Sun, 26 Jul 2015 19:51:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=PdG4eaqOaJ1mZVEQbfyFazHE69mYt4h9L7xzdu8W9Yk=; b=CvR8j7iOpyRZdKDSY3eLTEDSMKYc+xpO0jMMBX8+L/zs4UGuXWFjdSWDHhQtHJ2TAa SIdbEVVdLdeGRxfJj+YAUs58xJ2fy7so8LPBevsIOw4IajMNwJWMeBX/LfJluz9Gjk3E w94pB+0TTdD8pl98wR9ypqyOhdLxJjGsLFg5fZf1RzHUwXGsKCad74JYSVR9/iyZWnoJ HXlF3lBM+ELne5rrpg0pDrmj9eNSky0QjbYuNmH5Zl4X7O6mx/QsEDzKUqGVCt9q3wlB GLDsUj1wYDpJEBJP61m6/LPvilJs4LnF3SQWIbeLdunhWYI8Ds3GZxkOXRDMYBAWXhOF N+7g== X-Gm-Message-State: ALoCoQmwTMy52ZqXGF29iVfGn8EDYNckwQsW6OkTAnWrNseWMTbEZxX/ZjZaOEOV0dAK1nzlFahM X-Received: by 10.107.9.231 with SMTP id 100mr7749493ioj.12.1437965478229; Sun, 26 Jul 2015 19:51:18 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.108.163 with SMTP id j32ls2556583qgf.27.gmail; Sun, 26 Jul 2015 19:51:16 -0700 (PDT) X-Received: by 10.140.85.232 with SMTP id n95mr440188qgd.21.1437965476868; Sun, 26 Jul 2015 19:51:16 -0700 (PDT) In-Reply-To: <47831edb-dbc1-413e-9886-95e357c3bf20@isocpp.org> X-Original-Sender: isocppgroup@denisbider.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:19296 Archived-At: ------=_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
Sorry for the spam, but -

Wi= th respect to this:

> > And besides, you can= 't test for all compiler=C2=A0bugs this way.
> Not all, bu= t one can test for most everything that has to do with syntax.
You can put a static_assert in the test block, too, a= nd thereby test for anything that the compiler can evaluate at compile time= ;=C2=A0including 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 t= hat.

Of course, I don't actually use Clang= ... ;)
=C2=A0

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 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.

&= gt; True, but there shouldn't be differences in compiler implementation= s.

There is a tremendous amount of hubris in this = single word, "should". If you had the power to cause com= piler implementations to be consistent, you wouldn't need this registry= to begin with.

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.

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 al= l compiler=C2=A0bugs this way.

Not all, but one c= an test for most everything that has to do with syntax.


O= n Sunday, July 26, 2015 at 7:17:41 PM UTC-6, Thiago Macieira wrote:
On Sunday 26 July 2015 18:03:16 denis bider wrot= e:
> 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 mor= e than any=20
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 implementation= s. Different=20
revisions of a feature can be marked by different dates on the feature = macro,=20
such as __cpp_constexpr has done.

Compiler bugs should be fixed. And besides, you can't test for all = compiler=20
bugs this way.

> > Sentinel compilation would imply a major feature to the langu= age.
> > You can already do that with a configure script, if you want,= though.
>=20
> That opens a whole other can of worms, which sentinel compilation = would
> make it easy to avoid.

--=20
Thiago Macieira - thiago (AT) macieira= ..info - thiago (AT) kde.org
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4= 5358

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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/<= /a>.
------=_Part_2487_997462932.1437965476328-- ------=_Part_2486_1244313517.1437965476328-- .