220 19328 <726831ee-89c5-4bc5-96cc-6d5855843a03@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: Mon, 27 Jul 2015 15:24:59 -0700 (PDT) Lines: 301 Approved: news@gmane.org Message-ID: <726831ee-89c5-4bc5-96cc-6d5855843a03@isocpp.org> References: <1646231.xfnxM1QXYz@tjmaciei-mobl4> <53281455.oCxcCYIyeX@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3521_2074053500.1438035899995" X-Trace: ger.gmane.org 1438035909 22859 80.91.229.3 (27 Jul 2015 22:25:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2015 22:25:09 +0000 (UTC) Cc: thiago@macieira.org To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBPG73KWQKGQE4QYU3NQ@isocpp.org Tue Jul 28 00:25:09 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f200.google.com ([209.85.213.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZJqpS-00056q-LJ for gclcip-std-proposals@m.gmane.org; Tue, 28 Jul 2015 00:25:02 +0200 Original-Received: by igbqa2 with SMTP id qa2sf181740285igb.0 for ; Mon, 27 Jul 2015 15:25:01 -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=R25OxAlyORaKlV7r60UIFljZfpbjJP/J6IKRxLPW2Zg=; b=IADmKQjwv8BsEXdi0NvCTRS5VQ9RUK0+OAVbK9NFAhWI3nXQTPTkRg0E+K5//JmXM3 FQPw/rpJhCJnk5wW8KrA6eRf3fcBQT6uvBq33XjVH0RfIK58+WYt9V/KgXg+Cd9zCGFT iwGO8JVFtpOw/Ig5mWgpS3BbbaZCyl5896XKPc1PoDBJrkhni+8hcPBJqwxuVJ5K7dUl 2BTctO79wjylxn1vErKKNlfcbyYr0h3E5IXRUCKDGmPTHmozmwXarSxmtakfHmPEUCEY l64rpSu3dnbkjvx4D6U6a62I/wlC27JZmfcSNKS45UIRKHVcrg2NSNE4JjO9yV5q5XSc xRfQ== X-Gm-Message-State: ALoCoQmauafqZJ11gc09YZDqOPjFpXMJAe6GfP6u1/Uaetem1eQc/8db35nLSY/qFuuWtEjuFJ3/ X-Received: by 10.107.164.40 with SMTP id n40mr31158380ioe.30.1438035901674; Mon, 27 Jul 2015 15:25:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.21.209 with SMTP id 75ls1169329qgl.68.gmail; Mon, 27 Jul 2015 15:25:00 -0700 (PDT) X-Received: by 10.140.47.68 with SMTP id l62mr502440qga.42.1438035900691; Mon, 27 Jul 2015 15:25:00 -0700 (PDT) In-Reply-To: <53281455.oCxcCYIyeX@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:19328 Archived-At: ------=_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
Yeah... You're right about the second phase of te= mplate lookups.

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.

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.

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?


On Sunday, July 26, 201= 5 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.
>=20
> 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 direct= ive.
>=20
> The first line that's a preprocessor directive marks the end o= f the test
> block.

That sounds over-simplistic. What if the test requires the second phase= of=20
template lookups? The compiler may not be ready to do that just yet, gi= ven its=20
architecture. For example, I don't trust GCC's -fsyntax-only op= tion: in the=20
past, it would not find all syntax errors unless you actually compiled = the=20
code.

What you're asking for is that the compiler copy its state, launch = a new=20
process and treat the program as ending there, then report back. That m= ight be=20
very costly in some operating systems -- if it's possible at all, a= s it the=20
compiler process might have grown very big already (ever tried compilin= g one=20
of WebKit/Blink's AllInOne.cpp files?).

So why not use a configure script? This has been done for 30 years and = the=20
technology is proven. Not only that, this kind of tests can be done onc= e for=20
many sources and they can detect link failures too. It might be more=20
inconvenient, but it's a superior solution.

> Obviously. But once implemented, my proposal provides eternal,
> general, universal feature testing support.
>=20
> 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
>=20
> 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 wha= t
> 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 sys= tem.

Sure it can. In fact, I don't know a single non-trivial library tha= t allows=20
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 o= f 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 wh= at the
> compiler supports.

Oh, I see what you mean. You mean detecting features at the time of com= piling=20
the user's code.

That can easily be solved by removing the problem altogether. Determine= the=20
features supported at the time of compiling the library itself and writ= e a=20
config.h-like file (just don't call it "config.h"). The f= eatures supported at the=20
time you compiled the library will still be supported at the time the l= ibrary=20
is used. Compiler downgrades are not possible for a lot of reasons, so = this=20
would be the least of the problems.

The only issue would be sideways update, like switching from GCC to Cla= ng or=20
to ICC or another permutation that generates binary-compatible output.

But in any case, we went back to #ifdef'ery, which is helped by hav= ing=20
standard macros so you don't have to write a config.h file.
--=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_3522_771965206.1438035899995-- ------=_Part_3521_2074053500.1438035899995-- .