220 19294 <2a1df8fc-7d85-4c27-a8c7-102791d2fcf6@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:36:07 -0700 (PDT) Lines: 191 Approved: news@gmane.org Message-ID: <2a1df8fc-7d85-4c27-a8c7-102791d2fcf6@isocpp.org> References: <1720943.XpK8Tt98Hf@tjmaciei-mobl4> <4897684.zJq850IzGK@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2490_1839548734.1437964567810" X-Trace: ger.gmane.org 1437964586 11988 80.91.229.3 (27 Jul 2015 02:36:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2015 02:36:26 +0000 (UTC) Cc: thiago@macieira.org To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBGFS22WQKGQE5XQQBSA@isocpp.org Mon Jul 27 04:36:18 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZJYH1-0003ET-PB for gclcip-std-proposals@m.gmane.org; Mon, 27 Jul 2015 04:36:15 +0200 Original-Received: by obbop1 with SMTP id op1sf130425818obb.3 for ; Sun, 26 Jul 2015 19:36:09 -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=eJzoPXNxvhwuFJrdGvBQc7hRBqgxPD6Y9ycT85Wlh8Q=; b=bMpuUtPMxs7vaKFkBJ1/CPliIW2RTol+sIVCPJ0UkpOMSyxe2lHB9IjFHRRfoDRJ1F lhQ2mfR0N0yvy1Ht3c7BhPOTBo1TG0GlCYF/yGsBavfvTLw8BPb3GTbydkV05mvf7Cjj uMyk/aAjq9Jre3aN7ChryOoUgkqKsRU9VVQKzDzY3Igi2hN5fMrcRyfYOSJ+9NUIha97 /AwXBItbgvTyF4gx/FdntY8dcZcI13glw5tQYvoMHWoGoSMcPv2FJYIbmqC+8AS4vvPo K1Bvd+cHuabD9DW0AR+zSiS+aMLQCOveavrZpyM2jAOlShHOPwq68TLtUu2t6A6ksiVZ 0Smw== X-Gm-Message-State: ALoCoQnEusGM9Hzby8nytDzzxBu5YuqwjwwfdCpboxBMckqTXe9eGOXD4TplCV+zG3pJnTEVjj6s X-Received: by 10.182.205.232 with SMTP id lj8mr28619953obc.22.1437964569685; Sun, 26 Jul 2015 19:36:09 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.101.150 with SMTP id u22ls2696052qge.85.gmail; Sun, 26 Jul 2015 19:36:08 -0700 (PDT) X-Received: by 10.140.37.129 with SMTP id r1mr436847qgr.18.1437964568323; Sun, 26 Jul 2015 19:36:08 -0700 (PDT) In-Reply-To: <4897684.zJq850IzGK@tjmaciei-mobl4> 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:19294 Archived-At: ------=_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
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.
<= br>
> 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 nee= d this registry to begin with.

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.
<= br>
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;.


> And besides, you can'= t test for all compiler=C2=A0bugs this way.

Not a= ll, but one can test for most everything that has to do with syntax.
<= div>

On Sunday, July 26, 2015 at 7:17:41 PM UTC-6, Thiago Macieira w= rote:
On Sunday 26 July 2015 18:03:16 den= is 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 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_2491_978443330.1437964567810-- ------=_Part_2490_1839548734.1437964567810-- .