220 30832 <274e92cb-25e3-4e32-b13e-6d419cd8c5e3@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Gonzalo BG Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Detecting compile-time evaluation Date: Thu, 9 Feb 2017 05:33:35 -0800 (PST) Lines: 89 Approved: news@gmane.org Message-ID: <274e92cb-25e3-4e32-b13e-6d419cd8c5e3@isocpp.org> References: <86a47916-27c3-4e29-862f-9b4e1f105c1c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_205_1427550062.1486647215406" X-Trace: blaine.gmane.org 1486647221 13174 195.159.176.226 (9 Feb 2017 13:33:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 9 Feb 2017 13:33:41 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDTOBQEKX4PRBMG76HCAKGQEK3O6P4A@isocpp.org Thu Feb 09 14:33:32 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f70.google.com ([74.125.83.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cboqp-0002yJ-5X for gclcip-std-proposals@m.gmane.org; Thu, 09 Feb 2017 14:33:31 +0100 Original-Received: by mail-pg0-f70.google.com with SMTP id 204sf4651286pge.5 for ; Thu, 09 Feb 2017 05:33:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :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=nz7Qm6setWY9B9JIPVeIhrszcvmNezVCCJ2Zice5loE=; b=KimS9ZrRbo/uYj+qSvOUPJwClFKg0BherY8H4Zf0HjAbEy+GflGRDRwu7Zl4VpurrI K+YTc60ZHlb+dQAMlrnnBmCPwU9un4/1M19kE3WgMxv1C4cHr8yw0pv19piuYDLmYIVq 40rDj9u5qI4S1iPPq9ZzTdgpLDJ53BDnnHnE5f3JCh/Dq5pyK2CY1m8TCpvprt5XdO+N 7ERvQmdTOfMBGK/GoWQPhvVrNSWTtlLPC0MmKtYHZmO5UN1OmgLCF+pg3mhMjmgliVPz mgn/hBnjzFV6wWJrhQ5iWIyTWbFpwdrfajtbxpeI6Qeyvud1qbH5mtHaAvh8LyspwT5I 2Lcg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :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=nz7Qm6setWY9B9JIPVeIhrszcvmNezVCCJ2Zice5loE=; b=NOIsrdWham1KBf77GCWgpBXLmd+hv6z5dLM2l8arx1+H9MLWgLMjdYA9eLsR/z+tcg avAVI/AB4oi1YHYNWPcXmN4sVgwmCa8RsP00p1VFnIcmDN3ZBUdEkSqYifIbMf+iH6cw BK1iPe352lQjdw5JPzP5U769zojPMfwfqHx5thAuUgOS7YbYxjO+jiEeplHGOPerYbff qm6RGkQGciqs77NZKNvTHz/GbnPUnw1Mz02UA2UbEdTlypXDWfMNuDqm7QwV11eZ53nz qSxE0D+Kf/t6y79IYlzDcWAssf0T36NHRRoxQJoXmULNc+fIFxkuBQ2i7yf65aMsi3kk FqQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version: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=nz7Qm6setWY9B9JIPVeIhrszcvmNezVCCJ2Zice5loE=; b=cyJuPrNUCC6Fl9PMf15xZkLmuQwXJdzvVWZStgh5FklG6wHvTZblzAdJ+bNPo0OXM1 lOevD83hqA2vy04gW5Ca7jGwezr9sYCDN5J31OCpsCj/Jel1CgsO4TBolGgpRTKy9nad 8uW3p692UxIsMu4DldgTP6veAj2CBJbqKx01AOwA+ElAKBSuYKr600/wgkGH88qGIoBM 2V8oSf54kpW+FJTix2CvzFpWJc5yep6H240FleInKevXx3ygGJl296aE3uC2Ib7uv+dl s5mKFT8Z3Zi89BnpHo1GvfHOeaQLoz2YYfatkdWEWmXRbJI458C51sGUEiQlfynC9Sum 08WQ== X-Gm-Message-State: AMke39nSJ2W4o+dayD5eovjlBhiHZlcxJHGz4Fiv2zTbG7hJGgBAK4mldNet5EXgoElYfw== X-Received: by 10.99.56.4 with SMTP id f4mr982740pga.37.1486647216578; Thu, 09 Feb 2017 05:33:36 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.59.194 with SMTP id k60ls10561562otc.22.gmail; Thu, 09 Feb 2017 05:33:35 -0800 (PST) X-Received: by 10.157.16.48 with SMTP id h45mr125338ote.10.1486647215841; Thu, 09 Feb 2017 05:33:35 -0800 (PST) In-Reply-To: <86a47916-27c3-4e29-862f-9b4e1f105c1c@isocpp.org> X-Original-Sender: gonzalobg88@gmail.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:30832 Archived-At: ------=_Part_205_1427550062.1486647215406 Content-Type: multipart/alternative; boundary="----=_Part_206_2053102133.1486647215406" ------=_Part_206_2053102133.1486647215406 Content-Type: text/plain; charset=UTF-8 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-critical-functions-td4027593.html > > -- 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/274e92cb-25e3-4e32-b13e-6d419cd8c5e3%40isocpp.org. ------=_Part_206_2053102133.1486647215406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In [0] Chandler Carruth discusses a different approach usi= ng attributes that is nicer:

// constexpr implementation
constexp= r int foo_constexpr_impl();

// run-time implementation with fallback=
// to the constexpr implementation in=C2=A0
// constant-eval= uated 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:<= br>
Yes, I com= pletely agree, but I don't think this solves the whole=C2=A0
problem= {{referring to improving constexpr}}. There are certain constructs which w= e are unlikely to *ever*
permit in constexpr functions, such as (as an = extreme case) inline
assembly. Where possible, we should share an imple= mentation between
compile time and runtime. This proposal is for the ex= ceptional 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-t= o-allow-constexpr-to-be-applied-to-performance-critical-functions-td4027593= ..html

--
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/274e92cb-25e3-4e32-b13e-6d419cd8c5e3= %40isocpp.org.
------=_Part_206_2053102133.1486647215406-- ------=_Part_205_1427550062.1486647215406-- .