220 19301 <53281455.oCxcCYIyeX@tjmaciei-mobl4> article Path: news.gmane.org!not-for-mail From: Thiago Macieira Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Testing for supported features: Per-feature macros? Sentinel compilation? Date: Sun, 26 Jul 2015 21:35:13 -0700 Lines: 88 Approved: news@gmane.org Message-ID: <53281455.oCxcCYIyeX@tjmaciei-mobl4> References: <1646231.xfnxM1QXYz@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1437971739 10213 80.91.229.3 (27 Jul 2015 04:35:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2015 04:35:39 +0000 (UTC) Cc: ISO C++ Standard - Future Proposals To: denis bider Original-X-From: std-proposals+bncBCB4TK757YBRBCXK22WQKGQEAOUBVBY@isocpp.org Mon Jul 27 06:35:24 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f70.google.com ([209.85.215.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZJa8J-00037E-PR for gclcip-std-proposals@m.gmane.org; Mon, 27 Jul 2015 06:35:23 +0200 Original-Received: by laef2 with SMTP id f2sf23470356lae.0 for ; Sun, 26 Jul 2015 21:35:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=m2Z2ofcGEl9usIsB9yljcvRCEggVGIiIZpCfYjztdvY=; b=bUnsu+52uvjVz8I7vOLGD7EtEJmTA/QSj+ef8ll10CS5VdApk9C7rUIK+EbSB3IFXM VUHdEphstgWvtm4vLuDSPCe0U0TfFKuDwwRHEmXWmo79+pU/wb//ctfaCb2Ntj2VTDVp CBHuD/WGuIM75G2Kl878lwhntv7kMs18NO/YgC26l/m1vpjULU39WXXK/dvZkcfX7RwE nVEOMZaTHPU99moZPt8ZqZ7ucOd36wBTbVN1exboI1Y06I7BFL6mWV6p7R3QrtoT0fk9 MP9AoKOzvI1FAwXQ5JL1ZCXmrStZ+Z96jljZgd2FA2MsnAYhRzJgdtWewOy7RdL5Gmf1 /K X-Gm-Message-State: ALoCoQndIu0ytJnZaxKgMWA7FvxwGwOOIFG4h7oQ5wmnlbtgwLMAaC8cvnDi9k2onx06uAYV7obm X-Received: by 10.112.99.37 with SMTP id en5mr11243542lbb.7.1437971722756; Sun, 26 Jul 2015 21:35:22 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.78.169 with SMTP id c9ls548904wix.42.canary; Sun, 26 Jul 2015 21:35:21 -0700 (PDT) X-Received: by 10.180.90.83 with SMTP id bu19mr20262082wib.91.1437971721537; Sun, 26 Jul 2015 21:35:21 -0700 (PDT) Original-Received: from gondolin.macieira.info (gondolin.macieira.info. [78.47.120.188]) by mx.google.com with ESMTP id wp9si28651742wjb.181.2015.07.26.21.35.21 for ; Sun, 26 Jul 2015 21:35:21 -0700 (PDT) Received-SPF: pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) client-ip=78.47.120.188; Original-Received: from tjmaciei-mobl4.localnet (unknown [IPv6:2601:1c0:5803:81c9:a88d:786e:676b:dda3]) by gondolin.macieira.info (Postfix) with ESMTPSA id A01EC11B50A; Sun, 26 Jul 2015 21:35:20 -0700 (PDT) User-Agent: KMail/4.14.9 (Linux/4.0.5-3-desktop; KDE/4.14.9; x86_64; ; ) In-Reply-To: X-Original-Sender: thiago@macieira.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) smtp.mail=thiago@macieira.org 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:19301 Archived-At: 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/. .