220 39515 <1c719172-4ea9-4cfc-b491-d1c7da7ccaac@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: chatham130@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: constexpr! or constexpr(true) Date: Thu, 2 Aug 2018 23:19:45 -0700 (PDT) Lines: 143 Approved: news@gmane.org Message-ID: <1c719172-4ea9-4cfc-b491-d1c7da7ccaac@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_508_1442704176.1533277185196" X-Trace: blaine.gmane.org 1533277062 12591 195.159.176.226 (3 Aug 2018 06:17:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 3 Aug 2018 06:17:42 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCN5HEMFRYKRBAXIR7NQKGQEBAW6CYI@isocpp.org Fri Aug 03 08:17:38 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f200.google.com ([209.85.213.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1flTP6-0003AU-Ky for gclcip-std-proposals@m.gmane.org; Fri, 03 Aug 2018 08:17:36 +0200 Original-Received: by mail-yb0-f200.google.com with SMTP id i15-v6sf3804059ybk.18 for ; Thu, 02 Aug 2018 23:19:47 -0700 (PDT) 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=aW+GnibXJy5G0cimg1iD8X7WbAvnFfEenB8Y3gxp8fA=; b=TKbZC1hFCvOjznYpn/MPh95foWwXUCI1Jm83Lkk5ZoUdPeUVa8hH289aUvrZ1NHQyu 6qac0DvQkNLAbUGkmNw5Oo11ryXe/L7QP5d41Zw8+nYinPr04t2VieXe8Y4905HPOvzQ yfAYsY7NL57beIMvybdE8tc6MHtqQLKJeEwcvUc1Oqd0z1NiOljXpNP91z3J1qu1Jd+B r1+08bJb9CjARsJp8GAkoZQYghTjLnQFXaXjAMH3XYne+YSTlJjohuEC+5YoyVkOsDBA W/JDcDLR8VPQf95aT/0HBFSzhMfWbiZt3QqFmguKl6pJ4ueiYnGGrFLaR15krup4opgf oGdQ== 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=aW+GnibXJy5G0cimg1iD8X7WbAvnFfEenB8Y3gxp8fA=; b=YV5u1/v4xen1R7fZKM7ZqX1e8D/DdVUPC0hoAVuA9W2DUW41G5Ll6yUQKOzGj6/1fl SJghicQ3unYaGuI1OnZkORz9/JspBYSVmt7imaOPr2h27SZDt2U8CnUaBj5s4eyF73FK cVsFp9pftypJZkH8ARBAe7m/zmUkeHIfQac+MNMrLtgiNJyykhkny4VvvLVnlvPGpnsl Cl4SXe3SLNkkcFqSbIYsPjjjTDQ7FVuTIZv4kAlShqv1Ji9nR5nn1wqdkFd6JyWjz0gp LKaV54UaXgk5J0hKxlihpmnmQdkfO0P82NXykzoXGSc7pI8yxSWZAeMR70yIk0PTB7db U7dw== 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=aW+GnibXJy5G0cimg1iD8X7WbAvnFfEenB8Y3gxp8fA=; b=VSZaNb+ESTOMOs9UVjL9vVEwnp24niF+EQmTcK1GzN4D2iD2mrFXXCI7SstVZURQfZ iAdkrapBtnXYJCnS7NFedXcWThvOrZVOJWYY/hRl1suPVrMKfiApJtVIvSfv/lGhzU2W 1IXtMAU6vwwAbXEnv37lQ03NXN6j7Jhl9WwXWeGsPHb4SLdLOgrflSr8fhOYSdU3N9x4 lSm2450JGZ7r3RxOcnj4XnWG8Vrf9bRiLfBIrQNTpI+ziFh076W4hpI+niCgO1f13KDK vHuaYTYRpq+l1xZom2uQQ9bLb/IwR8JMbypjljBQXGgo7wNp+06Nn+YmF0qu+y+T3FQF ARHQ== X-Gm-Message-State: AOUpUlFaH5qb78NBPz+8kdZJbObyMvNhH8u7gr54jKhTUVyLZhgFyYW6 Z+Fyv2A1x/F75QVsiHW0MkfHoA== X-Google-Smtp-Source: AAOMgpfpqWVZKDDyyxzRfp/oXFFGxpWQaw/HRnQijYTDZyw0PZtKqdexrzP5HXtz8jFkrUwBPfvCHw== X-Received: by 2002:a81:ad64:: with SMTP id l36-v6mr1851464ywk.8.1533277187102; Thu, 02 Aug 2018 23:19:47 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:778b:: with SMTP id s133-v6ls692505ywc.15.gmail; Thu, 02 Aug 2018 23:19:45 -0700 (PDT) X-Received: by 2002:a81:a611:: with SMTP id d17-v6mr132877ywh.2.1533277185791; Thu, 02 Aug 2018 23:19:45 -0700 (PDT) In-Reply-To: X-Original-Sender: chatham130@gmail.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:39515 Archived-At: ------=_Part_508_1442704176.1533277185196 Content-Type: multipart/alternative; boundary="----=_Part_509_1248835167.1533277185196" ------=_Part_509_1248835167.1533277185196 Content-Type: text/plain; charset="UTF-8" The constexpr will need to go after the parameters, so that it can express a condition that is dependent on the actual value of the parameters. An example is to control recursion. Perhaps: auto factorial(int n)->int constexpr(n<100) { if(n==0) return 1; else return n*factorial(n-1); } On Monday, July 9, 2018 at 8:04:11 PM UTC-4, gmis...@gmail.com wrote: > Hello everyone > > Have the authors of p10731r.html considered if this suggestion: > > constexpr(true) int sqr(int n) { > return n*n; > } > > is preferable and more consistent or flexible than this which they > currently propose: > > constexpr! int sqr(int n) { > return n*n; > } > > And would it offer the following possibility and would it be useful?: > > constexpr(some_condition()) int sqr(int n) { // constexpr this function on > certain conditions. > return n*n; > } > > Also many compilers support forceinline functionality etc. Perhaps this > should be standardized too now? > Therefore I think the authors might want to propose this too: > > inline(false) int sqr(int n) { // force inline. Or inline! if the > committee thinks best. > return n*n; > } > > Which might similarly allow this?: > inline(some_other_condiition()) int sqr(int n) { // force inline. Or > inline! if the committee thinks best. > return n*n; > } > > where some_other_condition might test for a certain platform or compile > where forcing inline or not might be desirable despite what the compiler > thinks. > > It seems to me using ! is a little unusual syntax and be less consistent > and flexible than what I'm proposing but I admit ! is shorter. > > I see such macros regarding forceinline in various code bases such as > libcxx's __config file. So perhaps forceinline's time has come too. > > What do the authors of p1073r1 and others think? > > Thanks > Show trimmed content > Click here to Reply > -- 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/1c719172-4ea9-4cfc-b491-d1c7da7ccaac%40isocpp.org. ------=_Part_509_1248835167.1533277185196 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The constexpr will need to go after the parameters, so tha= t it can express a condition that is dependent on the actual value of the p= arameters. An example is to control recursion. Perhaps:

= auto factorial(int n)->int constexpr(n<100) {
=C2=A0 =C2=A0= if(n=3D=3D0) return 1;
=C2=A0 =C2=A0else return n*factorial(n-1);=
}

On Monday, July 9, 2018 at 8:04:11 PM UTC= -4, gmis...@gmail.com wrote:
Hello everyone

Have the authors of=C2=A0p10731r.ht= ml considered if this suggestion:

constexpr(true) in= t sqr(int n) {
=C2=A0 return n*n;
}


is prefera= ble and more consistent or flexible than this which=C2=A0they currently pro= pose:

constexpr! int sqr(int n) {
=C2=A0 return= n*n;
}

And would=C2=A0it offer=C2=A0the follow= ing=C2=A0possibility and would it be useful?:

cons= texpr(some_condition()) int sqr(int n) { //=C2=A0constexpr this function=C2= =A0on certain=C2=A0conditions.
=C2=A0 return n*n;
}

Als= o=C2=A0many compilers support=C2=A0forceinline functionality etc. Perhaps t= his should be standardized too now?
Therefore I think the authors= might want to=C2=A0propose this too:

inline(false= ) int sqr(int n) { // force inline. Or inline! if the committee thinks best= ..
=C2=A0 return n*n;
}

Which might similarly= allow this?:
inline(some_other_condiition()) int sqr(int n)= { // force inline. Or inline! if the committee thinks best.
=C2=A0 retu= rn n*n;
}

where some_other_condition might=C2= =A0test for a certain platform or compile where forcing inline or not might= be desirable despite what the compiler thinks.

It= seems to me using ! is a little unusual syntax=C2=A0and be less consistent= and flexible than what I'm proposing but=C2=A0I admit ! is shorter.

I see such macros regarding forceinline in vari= ous code bases such as libcxx's __config file. So perhaps forceinline&#= 39;s time has come too.

What do the authors = of=C2=A0p1073r1 and others think?

Thanks
=
Show trimmed content
Click here to Reply
<= /div>

--
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/1c719172-4ea9-4cfc-b491-d1c7da7ccaac= %40isocpp.org.
------=_Part_509_1248835167.1533277185196-- ------=_Part_508_1442704176.1533277185196-- .