220 19297 <1552996.JRXHdIS1j3@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 20:19:19 -0700 Lines: 71 Approved: news@gmane.org Message-ID: <1552996.JRXHdIS1j3@tjmaciei-mobl4> References: <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: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1437967174 13548 80.91.229.3 (27 Jul 2015 03:19:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2015 03:19:34 +0000 (UTC) Cc: ISO C++ Standard - Future Proposals To: denis bider Original-X-From: std-proposals+bncBCB4TK757YBRBO6G22WQKGQEMRJXRAQ@isocpp.org Mon Jul 27 05:19:26 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f200.google.com ([209.85.217.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZJYwm-0003ms-B2 for gclcip-std-proposals@m.gmane.org; Mon, 27 Jul 2015 05:19:24 +0200 Original-Received: by lbbvz8 with SMTP id vz8sf22990305lbb.2 for ; Sun, 26 Jul 2015 20:19: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=WtXD3gdBn4ornw25t9xWmnVoKIob2R/kKRhD0H3xwkw=; b=AUjiwgEiptBFSttXUmFWsWAodZfrbFZ6UDLn5JToB7YIMwkk9pv+5ddYAfcBZ1F2p+ Qyer9KtGnHcYaDviFxpGcoHcdh6oz+5gYDU2hlH51Gsymdl0pZtWbSLQLCfajo4aGfDL JylsMpjt6xuZ3x22js9E5GdYJcarp0oUo+xe/tZ7ZG19+yd1nx/cU8tPkuTBKJh6rdjC DaBlQnLJxR3lDRG7mdOl+EtGjjC7b6oZM5KmkUtLN0zk53l4bsd6dKcDVe7eJG/chCxm 2kIurrqvHMwe/uypkrt1XfSmJvpBRzn4ZvjAmsj9r/56dhR+I7xTX9XuHBXzWGUo0vgL tz X-Gm-Message-State: ALoCoQkBfymz+C4Z+1Ohuyj+R/251x/j18DWza4tPpnUTlaGaVSkBaI/JdGhosUcpqU9UnqDs2Ls X-Received: by 10.112.26.5 with SMTP id h5mr11339460lbg.4.1437967163822; Sun, 26 Jul 2015 20:19:23 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.90.35 with SMTP id bt3ls544330wib.15.gmail; Sun, 26 Jul 2015 20:19:22 -0700 (PDT) X-Received: by 10.194.123.4 with SMTP id lw4mr48881423wjb.94.1437967162680; Sun, 26 Jul 2015 20:19:22 -0700 (PDT) Original-Received: from gondolin.macieira.info (gondolin.macieira.info. [78.47.120.188]) by mx.google.com with ESMTP id u7si11670455wiw.120.2015.07.26.20.19.22 for ; Sun, 26 Jul 2015 20:19:22 -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 C996111B526; Sun, 26 Jul 2015 20:19:21 -0700 (PDT) User-Agent: KMail/4.14.9 (Linux/4.0.5-3-desktop; KDE/4.14.9; x86_64; ; ) In-Reply-To: <2a1df8fc-7d85-4c27-a8c7-102791d2fcf6@isocpp.org> 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:19297 Archived-At: On Sunday 26 July 2015 19:36:07 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's been in Clang since 3.5 (at least, I didn't check earlier), GCC 5 and ICC 16. I don't think Microsoft added it to 2015, but they don't have much in terms of C++14 yet, which is where this becomes more useful. > 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. Aside from compatibility, you're right. The standard specifies how the feature should work, so there should be no difference. Different behaviour of a standard feature is a bug in the compiler or a defect in the standard, neither of which anyone wants. Extension functionality can be marked by their own ways. > > 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 still would, because none of the compilers suddenly implemented all of the features. They came over the course of years, so in order to use partial implementations, we still needed to check some kind of macro. > 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. Correct, which is why SG10 SD6 was not part of C++11 and is optional to implement. I was surprised to see it proposed as a paper. But we've been doing macro checking for years. Getting standard macro names goes a long way towards simplifying the checks. > 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. And you'd still need a macro for everything else that is not a compiler bug. -- 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/. .