220 19300 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 21:15:10 -0700 (PDT) Lines: 197 Approved: news@gmane.org Message-ID: References: <47831edb-dbc1-413e-9886-95e357c3bf20@isocpp.org> <255fd5fb-cf04-431f-a576-d30926b86674@isocpp.org> <1646231.xfnxM1QXYz@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2495_1560318121.1437970510266" X-Trace: ger.gmane.org 1437970528 26012 80.91.229.3 (27 Jul 2015 04:15:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2015 04:15:28 +0000 (UTC) Cc: thiago@macieira.org To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBT7A22WQKGQE2XGPMSY@isocpp.org Mon Jul 27 06:15:14 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vn0-f69.google.com ([209.85.216.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZJZon-000091-NF for gclcip-std-proposals@m.gmane.org; Mon, 27 Jul 2015 06:15:13 +0200 Original-Received: by vnav141 with SMTP id v141sf121820785vna.1 for ; Sun, 26 Jul 2015 21:15:12 -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=DXhHdhCxfpfaPdjICGaChCQFZxD6KeYgFPOQ1L0bzjo=; b=Fsflb2TYBRNJH/LPhxm8tBSlNF9CEixHrq0CDZHG6LxrYGt3Ria1gk2ufUX9n2nbOz DulUdAtG8wbLfDD+6JeGBm6+qkvTvJQ8lgy7PH61FX7AXsAK0ia7dJePHkpz8ggSGtJh Kj7qLPeC3OQN6veOxD5eNF/yFbFpd65ZJi3A7zNzDuGYrYVpi++jv8+j7vzE7ontmRjO feEl1lOe+yUQAs9KCyDqfu5xMn5pAsYufkEnQ5mFceFFTRoaFIX3p9kMa7LxEp/YRUqs fgO3BxaeDwiIgZo+vZrcScgqe069JMMZCGpIRYg77mI/S8tOiS2toJdGW9fiwbHHYMxJ BXWA== X-Gm-Message-State: ALoCoQk33ZkQcXvv/6adPljfD3f0HZDq0ZkthLNFy7Lx0DGXSmRaNmmvpIG5+/ieMVUxf6SJdGID X-Received: by 10.129.55.196 with SMTP id e187mr28061063ywa.20.1437970512337; Sun, 26 Jul 2015 21:15:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.20.69 with SMTP id 63ls2764986qgi.30.gmail; Sun, 26 Jul 2015 21:15:11 -0700 (PDT) X-Received: by 10.140.99.83 with SMTP id p77mr293919qge.3.1437970510917; Sun, 26 Jul 2015 21:15:10 -0700 (PDT) In-Reply-To: <1646231.xfnxM1QXYz@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:19300 Archived-At: ------=_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
Thiago:

> I'm skeptic= al how much the compiler could recover in case
> of a syntax i= t does not understand with your proposal.

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>

The first line that's a preprocessor directive= marks the end of the test block.

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.


Jim:

> Nor is your proposal; any new C++= feature of this sort
> would be unusable if you need to compi= le on
> sufficiently-old compilers.

= Obviously. But once implemented, my proposal provides eternal, general,=C2= =A0universal feature testing support.

The registry= approach, meanwhile, will be challenged and may fail in some way for every= new feature that is added.


> I&= #39;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 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>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.

If you can force selection of the tec= hnology platform, you don't have this problem.

<= br>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 th= is way.
> >=20
> > Not all, but one can test for most everything that has to do = with syntax.
>=20
> You can put a *static_assert* in the test block, too, and thereby = test for=20
> anything that the compiler can evaluate at compile time; *includin= g*=20
> 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 s= till be=20
parsed properly. You can't use either feature to test for syntax th= e compiler=20
does not support.

I'm skeptical how much the compiler could recover in case of a synt= ax it does=20
not understand with your proposal.
--=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_2496_1003193867.1437970510266-- ------=_Part_2495_1560318121.1437970510266-- .