220 30833 article Path: news.gmane.org!.POSTED!not-for-mail From: Mathias Gaunard Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Detecting compile-time evaluation Date: Thu, 9 Feb 2017 13:56:50 +0000 Lines: 97 Approved: news@gmane.org Message-ID: References: <86a47916-27c3-4e29-862f-9b4e1f105c1c@isocpp.org> <274e92cb-25e3-4e32-b13e-6d419cd8c5e3@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114f50da5e88f60548195a13 X-Trace: blaine.gmane.org 1486648615 32335 195.159.176.226 (9 Feb 2017 13:56:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 9 Feb 2017 13:56:55 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCN3ZE6W4GRBJXK6HCAKGQE4NXJLVA@isocpp.org Thu Feb 09 14:56:51 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f71.google.com ([74.125.82.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cbpDN-00080a-JD for gclcip-std-proposals@m.gmane.org; Thu, 09 Feb 2017 14:56:49 +0100 Original-Received: by mail-wm0-f71.google.com with SMTP id u63sf3915502wmu.0 for ; Thu, 09 Feb 2017 05:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :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=98YpSEIz3/OhNfbmldysqXsrAJspLrOgmqe7Pn0GlBc=; b=SZ9LmlW3yrAMAPt6yjofhUGd1Pputgb2rJYkGXhNAo3wcXoj51rVISUA0AletOj/hx qvdhQ0V7rT9iqIK5IexvLHE4fknTmCq238kXmQNvm7UxuHt8rGU64eKJ8nCOcI/stfAE EvldY6J5todlm2w6bQXfxXWg5gmfpDw/m6Mn58g6pK/eXlZ2t/s/CcTlOSpI13Mg67CL QwXcg20+wUWgfbgH9DAQUtFMDvykvgER2zaaFpukIffG7VRxlPTSqi1rt1Vnm23K88HB QI8G/kGjg1p5zs/uY7i0hOxAzhhQB+v5AU7XAVXGc76a2ARjAMJRgcgzsxxSXG7vlgja flmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to: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=98YpSEIz3/OhNfbmldysqXsrAJspLrOgmqe7Pn0GlBc=; b=LNqMcXNQhg9jAnbY8suJ/X4aSES/Dfm9aoWMAnLD49woIik5pbXuFmIMleuXbfQxi4 Z/11u5YVcumm2lRGkp2eTdErHjb9qUL3e2BKbymNG7DdJBjERVBHPCoL6inoYb/u/5jH 20jPS/sIkCfF/BjhrivF3/E5ynDrT657EVBEFeylVCIjJMvu5mziTkM4l1smjSLAI+wl 3s9nz+tm44NfrR/XjNLfnetcRh+P57mL8dg7YLDF3duIQtFqeDwIUQfevLfqOZrSVUc+ p2CZ1SkoAYrjEQP3U2KRXzEHypbItMDAmkpCYqVCvlayuRdICcTYARsybGU4NKsgtrqr ju7w== X-Gm-Message-State: AMke39mwRr88UcQ1OV5h8z7aFDVcVNYKibvVP2d6YY2VkL+FN+TCIZtaoblKMHMGXEQgGg== X-Received: by 10.28.63.65 with SMTP id m62mr920062wma.6.1486648614964; Thu, 09 Feb 2017 05:56:54 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.132.13 with SMTP id g13ls258625wmd.16.gmail; Thu, 09 Feb 2017 05:56:53 -0800 (PST) X-Received: by 10.223.174.199 with SMTP id y65mr3464771wrc.19.1486648613538; Thu, 09 Feb 2017 05:56:53 -0800 (PST) Original-Received: from 13.mo1.mail-out.ovh.net (13.mo1.mail-out.ovh.net. [178.33.253.128]) by mx.google.com with ESMTPS id 8si6169445wmq.139.2017.02.09.05.56.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 05:56:53 -0800 (PST) Received-SPF: pass (google.com: domain of mathias@gaunard.com designates 178.33.253.128 as permitted sender) client-ip=178.33.253.128; Original-Received: from player795.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo1.mail-out.ovh.net (Postfix) with ESMTP id 6A8BB4F0AC for ; Thu, 9 Feb 2017 14:56:52 +0100 (CET) Original-Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) (Authenticated sender: mathias@gaunard.com) by player795.ha.ovh.net (Postfix) with ESMTPSA id E12DC1200BB for ; Thu, 9 Feb 2017 14:56:51 +0100 (CET) Original-Received: by mail-qk0-f180.google.com with SMTP id u25so4724133qki.2 for ; Thu, 09 Feb 2017 05:56:51 -0800 (PST) X-Received: by 10.55.45.65 with SMTP id t62mr2898194qkh.31.1486648611076; Thu, 09 Feb 2017 05:56:51 -0800 (PST) Original-Received: by 10.12.175.228 with HTTP; Thu, 9 Feb 2017 05:56:50 -0800 (PST) In-Reply-To: <274e92cb-25e3-4e32-b13e-6d419cd8c5e3@isocpp.org> X-Gmail-Original-Message-ID: X-Ovh-Tracer-Id: 8440871603158300287 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelgedrkeehgdeftdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu X-Original-Sender: mathias@gaunard.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of mathias@gaunard.com designates 178.33.253.128 as permitted sender) smtp.mailfrom=mathias@gaunard.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:30833 Archived-At: --001a114f50da5e88f60548195a13 Content-Type: text/plain; charset=UTF-8 On 9 February 2017 at 13:33, Gonzalo BG wrote: > In [0] Chandler Carruth discusses a different approach using attributes > that is nicer: > > // constexpr implementation > constexpr int foo_constexpr_impl(); > > // run-time implementation with fallback > // to the constexpr implementation in > // constant-evaluated contexts > [[constexpr_alias(foo_constexpr_impl)]] > int foo(); > > I wonder what happened to this proposal. Gabriel Dos Reis argues there > that we should focus on making constexpr better, but Richard Smith argued: > > Yes, I completely agree, but I don't think this solves the whole >> problem {{referring to improving constexpr}}. There are certain >> constructs which we are unlikely to *ever* >> permit in constexpr functions, such as (as an extreme case) inline >> assembly. Where possible, we should share an implementation between >> compile time and runtime. This proposal is for the exceptional cases >> (which, over time, should become fewer and fewer), and as a stopgap >> measure while we work towards the right solution. > > > [0] http://clang-developers.42468.n3.nabble.com/C-11-new-builtin > -to-allow-constexpr-to-be-applied-to-performance-critica > l-functions-td4027593.html > I'd personally prefer to add constexpr as a qualifier on the parameters and overload based on that, that would be much more generic. Good luck extending C++ to make that work though. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya_zgzJKgyp7%3D%2Bmds3uNsDLVvv5ZsL3uCd_R_e%3DBQAvQQQ%40mail.gmail.com. --001a114f50da5e88f60548195a13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 9= February 2017 at 13:33, Gonzalo BG <gonzalobg88@gmail.com> wrote:
In [0] Chandl= er Carruth discusses a different approach using attributes that is nicer:
// constexpr implementation
constexpr int foo_constexpr_impl();
// run-time implementation with fallback
// to the constexpr imple= mentation in=C2=A0
// constant-evaluated contexts
[[constexpr_= alias(foo_constexpr_impl)]]
int foo();

I wonder what happene= d to this proposal. Gabriel Dos Reis argues there that we should focus on m= aking constexpr better, but Richard Smith argued:

Yes, I completely agree, but I don't t= hink this solves the whole=C2=A0
problem {{referring to improving conste= xpr}}. There are certain constructs which we are unlikely to *ever*
per= mit in constexpr functions, such as (as an extreme case) inline
assembl= y. Where possible, we should share an implementation between
compile ti= me and runtime. This proposal is for the exceptional cases
(which, over= time, should become fewer and fewer), and as a stopgap
measure while w= e work towards the right solution.

[0] http://clang-developers.42468.n3.nabble.com/C-11-new-builtin-= to-allow-constexpr-to-be-applied-to-performance-critical-function= s-td4027593.html

I'd pe= rsonally prefer to add constexpr as a qualifier on the parameters and overl= oad based on that, that would be much more generic.
Good luck ext= ending C++ to make that work though.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya_zgz= JKgyp7%3D%2Bmds3uNsDLVvv5ZsL3uCd_R_e%3DBQAvQQQ%40mail.gmail.com.
--001a114f50da5e88f60548195a13-- .