220 19295 <47831edb-dbc1-413e-9886-95e357c3bf20@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:43:43 -0700 (PDT) Lines: 204 Approved: news@gmane.org Message-ID: <47831edb-dbc1-413e-9886-95e357c3bf20@isocpp.org> References: <1720943.XpK8Tt98Hf@tjmaciei-mobl4> <4897684.zJq850IzGK@tjmaciei-mobl4> <2a1df8fc-7d85-4c27-a8c7-102791d2fcf6@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_466_1099434043.1437965023472" X-Trace: ger.gmane.org 1437965038 17737 80.91.229.3 (27 Jul 2015 02:43:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2015 02:43:58 +0000 (UTC) Cc: thiago@macieira.org, isocppgroup@denisbider.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBYFV22WQKGQEU4XMKHY@isocpp.org Mon Jul 27 04:43:52 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f199.google.com ([209.85.192.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZJYON-0002Mi-U0 for gclcip-std-proposals@m.gmane.org; Mon, 27 Jul 2015 04:43:52 +0200 Original-Received: by pdmf1 with SMTP id f1sf150461291pdm.2 for ; Sun, 26 Jul 2015 19:43:45 -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=cJ//sOKGrfNJ0zfACuEmGZKvB+0SAxpJqMNhxzCObGg=; b=QSjMRbAiwAokXbriJLrDjGlkaMZicsbmWLgiFINA7pkjYHdh90qgqwnt9RceQYJLF9 eGAVAkSg1DiZidixQoUMGo8qf9LmF7/CiJVyhD2GJ9wO2jUYrpZZ+ADDYpmVrnq2ztyI XGqN8eMdx8sHngU9gYQaou2EMw4oL9QWr7WVX9JHxbxH4QNCR0IbTmw/Tp2cnmydhCKh Lwt0ZJhaBwrRuP9U2ggJMOcbnzvHLqvU0u9FYRFuowbQSZkd0EfKk4Ut3nvJAQw3q9S4 cIcz0AODuD4OrX6F0DfCF7Iex7wJfH/bv51RaiFXCIP+piC/zQmD6sUNxBDJBXwFd3Ja uhmQ== X-Gm-Message-State: ALoCoQmzyumu7ShmP+rM/Hg97HkDQTkX1BKiM2+9LaJSRClTqU96BUTxkDgYZ8651SLUh4I2PXAY X-Received: by 10.70.43.164 with SMTP id x4mr27303327pdl.1.1437965025162; Sun, 26 Jul 2015 19:43:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.100.194 with SMTP id s60ls2591655qge.25.gmail; Sun, 26 Jul 2015 19:43:44 -0700 (PDT) X-Received: by 10.140.23.50 with SMTP id 47mr438327qgo.24.1437965024026; Sun, 26 Jul 2015 19:43:44 -0700 (PDT) In-Reply-To: <2a1df8fc-7d85-4c27-a8c7-102791d2fcf6@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:19295 Archived-At: ------=_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
Pardon me, I do have access to Clang, which implement= s that.

Of course, I don't actually use Cl= ang... ;)
=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= 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.

> True, but there shouldn't be differences in compiler impleme= ntations.

There is a tremendous amount of hubris i= n this single word, "should". If you had the power to ca= use compiler implementations to be consistent, you wouldn't need this r= egistry to begin with.

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.

Now, look at what we actually got. All because some well-meaning peop= le, a few years in the past, thought that compilers "should".


> And besides, you can't test f= or all compiler=C2=A0bugs 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 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_467_2063905445.1437965023472-- ------=_Part_466_1099434043.1437965023472-- .