220 17331 article Path: news.gmane.org!not-for-mail From: Alexander Marinov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: constexpr function arguments Date: Sun, 12 Apr 2015 08:34:51 -0700 (PDT) Lines: 781 Approved: news@gmane.org Message-ID: References: <1799313.qMEWgUf3zn@lastique-pc> <2811449.Gbl9WO8oH6@lastique-pc> <2768024.05U7k9dJ4x@lastique-pc> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_299_1292937151.1428852891915" X-Trace: ger.gmane.org 1428852898 5442 80.91.229.3 (12 Apr 2015 15:34:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Apr 2015 15:34:58 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDBNZXHN2QPRBHFBVKUQKGQEQCTHZFQ@isocpp.org Sun Apr 12 17:34:57 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f198.google.com ([209.85.192.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YhJuR-0001Eo-Hv for gclcip-std-proposals@m.gmane.org; Sun, 12 Apr 2015 17:34:56 +0200 Original-Received: by pdlj11 with SMTP id j11sf120728511pdl.0 for ; Sun, 12 Apr 2015 08:34:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=xIKXvAMISsz+kB7PXOjklICofJqClGbMwO8cgDGt5fQ=; b=Y98wZo/jRRY+OlhTGBracWmSA7V1pGxC+ad7hIADPSRMtxgqk1+9d8hnlSH8rcHhw0 UnUAZnApk3x22yRiOWhdAHgnqRemEWwUdpcmOsmdWPsHjaUhyWzXqoRBPtfVZ9yT/BX+ /T1NX256JsvS3taHET9w5sn6G3Ww0kJoRFtNHKH8YTR9q7j/kDX1lDqm+CTgvFbaRtuY 5piSiNrygSKyVVCaY1JSMJhjIm2GNP/02JUKEi3eMefzM86SRxZ04aVUpeO2T4U8XNE/ jwCUb5OmQp35y9ir+PNYHAPO1+UbGAg1GBdcYt1a309MnxEuCwY9QEPcznI9w9GxKKjS iPWQ== X-Gm-Message-State: ALoCoQn3jiMiSao8fleMd3GyIPRPQJjnM76SB3NoQi8hHcI2P+zqmz3c6F5K7Z7NdWnnupeGdKUW X-Received: by 10.66.101.100 with SMTP id ff4mr14628198pab.24.1428852893479; Sun, 12 Apr 2015 08:34:53 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.96.67 with SMTP id j61ls2397958qge.67.gmail; Sun, 12 Apr 2015 08:34:52 -0700 (PDT) X-Received: by 10.140.91.47 with SMTP id y44mr118908qgd.39.1428852892546; Sun, 12 Apr 2015 08:34:52 -0700 (PDT) In-Reply-To: <2768024.05U7k9dJ4x@lastique-pc> X-Original-Sender: sasho648@mail.bg 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:17331 Archived-At: ------=_Part_299_1292937151.1428852891915 Content-Type: multipart/alternative; boundary="----=_Part_300_7672864.1428852891915" ------=_Part_300_7672864.1428852891915 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 12 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 201= 5 =D0=B3., 17:16:09 UTC+3, Andrey Semashev =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > > On Sunday 12 April 2015 06:13:35 Alexander Marinov wrote:=20 > > You read my proposal - it does the same thing you want even if you don'= t=20 > > fully understand it.=20 > > I did read it, and I still don't think it covers my case. In fact, I'm no= t=20 > sure I agree with your proposal.=20 > > > Actually 'constexpr' is a useless keyword - it adds nothing to 'inline'= =20 > > functions which most compilers already optimize out and evaluate at=20 > > compile-time if possible.=20 > > It adds a _requirement_ on the function to be evaluated at compile time,= =20 > provided that its arguments are also constexpr. It also adds certain=20 > restrictions on the function body. There is no such requirement or=20 > restrictions for inline functions, and in fact even the most trivial=20 > inline=20 > functions are allowed to not be inlined or optimized. And this is the cas= e=20 > in=20 > debug builds, for instance, when compilers don't do any inlining at all= =20 > but=20 > are still bound to evaluate constexpr at compile time.=20 > Actually it doesn't, neither 'constexpr' do. A call to 'constexpr' is done= =20 the same way to a normal function so it's still a compiler decision if it's= =20 going to evaluate it at compile-time. The only case where this is required= =20 is when such function is instanced at place where constant-expression is=20 expected. I don't see any reason not to implicitly enable this feature to= =20 'inline' functions too. Actually 'constexpr' functions are inline by=20 default. Examples of current standard: constexpr /*imagine < this was not there */ inline int func(int a) { return= =20 a * 4; } //note the above declaration is the same if 'inline' was not there because= =20 it's implicitly implied by 'constexpr' int b; int main(){ float arr[func(b)]; //here 'func' should be evaluated at compile-time= =20 but this is currently not possible - error int runtime =3D func(b); //ok, here 'func(b)' is evaluated at 'run-time= ' float arr1[func(9)]; //ok, here 'func(b)' is evaluated at 'compile-time= ' int compilerdec =3D func(9); //ok, here 'func(b)' is evaluated either a= t=20 'run-time' or 'compile-time' } Note that the above is a real working example. You can test it online here= =20 . About the function requirements - I really think that they are decided on= =20 no real basis and I that they should be removed all. At first 'constexpr'= =20 function should consist only of a return statement, later this requirement= =20 was lifted. I think now it's high-time to lift them all. =20 > > What you're suggesting is essentially mandate a certain level of compiler= =20 > optimization as a language feature. I'm not sure this is a good idea.=20 > > > The part which fulfill your idea is 'inline' variables which are=20 > guaranteed=20 > > to be evaluated at run-time (as template parameters)=20 > > I assume, you meant "compile-time" here?=20 > Yeah - sorry - common mistake of mine. =20 > > > and more specially=20 > > 'inline' function parameters (which imply that the function they=20 > > declare/define is 'inline' because templates can't be defined at=20 > different=20 > > TU).=20 > >=20 > > So your example will look like this by using my construct:=20 > >=20 > > template< typename T >=20 > > void atomic::store(T val, inline memory_order order)=20 > > {=20 > > switch (order) // order is always constexpr=20 > > {=20 > > // implementations with different memory ordering guarantees=20 > > }=20 > >=20 > > }=20 > >=20 > > With the exact same semantics you want. Function parameter 'order' will= =20 > > accept only constant-expressions and it will be evaluated at=20 > compile-time.=20 > > Yes, that would be my proposal, although I would still use constexpr=20 > keyword.=20 > I didn't find inline variables in your proposal thread, sorry if I missed= =20 > it.=20 > Why polite the source code with another new keyword as we can reuse an=20 existing one. =20 > > > Actually those semantics are possible now too but have different=20 > > syntax(etc. by using template parameters):=20 > >=20 > > template< typename T, memory_order order >=20 > > void atomic::store(T val)=20 > > {=20 > > switch (order) // order is always constexpr=20 > > {=20 > > // implementations with different memory ordering guarantees=20 > > }=20 > >=20 > > }=20 > > Sure. In fact, I would have defined std::atomic interface this way myself= =20 > in=20 > the first place. I guess, we have it defined the way it is to support=20 > C-style=20 > interface? Anyway, we have what we have, and my proposal attempts to=20 > improve=20 > it.=20 > > > =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 12 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB= 2015 =D0=B3., 15:29:21 UTC+3, Andrey Semashev =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0:=20 > > > On Sunday 12 April 2015 05:09:29 Alexander Marinov wrote:=20 > > > > I already sketched the details of this idea. You can read it here= =20 > > > > <=20 > > >=20 > > >=20 > https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/RTss7U= y=20 > > > l=20 > > >=20 > > > > zgQ>. Only someone needs to write a proposal and/or implement it as= =20 > a=20 > > >=20 > > > demo=20 > > >=20 > > > > in some open-source compiler (GCC or Clang).=20 > > >=20 > > > No, I don't think your proposal is related to my idea. I'm not trying= =20 > to=20 > > > make=20 > > > a function constexpr, I'm trying to propagate compile-time nature of= =20 > some=20 > > > of=20 > > > its arguments to its body, which is executed in run time.=20 > > >=20 > > > (offtopic: And I do think that inline and constexpr are different=20 > > > properties=20 > > > of the code, even though they are somewhat related on the=20 > implementation=20 > > > side;=20 > > > I do not think they should be mixed together in a single keyword.)=20 > > >=20 > > > > =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 12 =D0=B0=D0=BF=D1=80=D0=B8= =D0=BB 2015 =D0=B3., 13:33:17 UTC+3, Andrey Semashev =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0:=20 > > > > > Hi,=20 > > > > >=20 > > > > > I wonder if constexpr function arguments would be a useful=20 > addition to=20 > > >=20 > > > the=20 > > >=20 > > > > > standard. Consider this part of std::atomic interface:=20 > > > > > template< typename T >=20 > > > > > void atomic::store(T val, memory_order order)=20 > > > > > {=20 > > > > > =20 > > > > > switch (order)=20 > > > > > {=20 > > > > > =20 > > > > > // implementations with different memory ordering guarantee= s=20 > > > > > =20 > > > > > }=20 > > > > > =20 > > > > > }=20 > > > > >=20 > > > > > The function itself is not constexpr because the implementation= =20 > has a=20 > > > > > runtime=20 > > > > > side effect. However the memory order argument is always constant= =20 > in=20 > > > > > normal=20 > > > > > uses and the implementation could have had benefitted from knowin= g=20 > > >=20 > > > this=20 > > >=20 > > > > > constant at compile time. The current standard does not offer=20 > means=20 > > >=20 > > > for=20 > > >=20 > > > > > that,=20 > > > > > so you're out of luck if the compiler is not smart enough to=20 > propagate=20 > > > > > this=20 > > > > > constexpr hint behind the scenes. For the most part with compiler= s=20 > I=20 > > >=20 > > > have=20 > > >=20 > > > > > experience with (gcc, icl, msvc) this only works when the compile= r=20 > is=20 > > >=20 > > > able=20 > > >=20 > > > > > to=20 > > > > > inline the function call.=20 > > > > >=20 > > > > > BTW, if anyone wonders if compiler intrinsics help here, no they= =20 > > >=20 > > > don't.=20 > > >=20 > > > > > With=20 > > > > >=20 > > > > > the code similar to this:=20 > > > > > template< typename T >=20 > > > > > void atomic::store(T val, memory_order order)=20 > > > > > {=20 > > > > > =20 > > > > > __atomic_store_n(&m_value, val, order);=20 > > > > > =20 > > > > > }=20 > > > > >=20 > > > > > gcc and icl simply fall back to memory_order_seq_cst regardless o= f=20 > the=20 > > > > > specified order if they cannot inline the function. This always= =20 > > >=20 > > > happens in=20 > > >=20 > > > > > debug, for instance.=20 > > > > >=20 > > > > > What I'm thinking is if we could require some argument to be=20 > constexpr=20 > > >=20 > > > and=20 > > >=20 > > > > > pass that 'compile-timeness' hint to the function body, the=20 > > >=20 > > > implementation=20 > > >=20 > > > > > could optimize better. For example:=20 > > > > > template< typename T >=20 > > > > > void atomic::store(T val, constexpr memory_order order)=20 > > > > > {=20 > > > > > =20 > > > > > switch (order) // order is always constexpr=20 > > > > > {=20 > > > > > =20 > > > > > // implementations with different memory ordering guarantee= s=20 > > > > > =20 > > > > > }=20 > > > > > =20 > > > > > }=20 > > > > >=20 > > > > > In this case the switch/case would always be optimized to a singl= e=20 > > >=20 > > > case.=20 > > >=20 > > > > > And=20 > > > > > the intrinsic-based version would also work as intended. Also, if= =20 > we=20 > > >=20 > > > have=20 > > >=20 > > > > > a=20 > > > > > non-constexpr overload of this function we would also support=20 > calling=20 > > >=20 > > > with=20 > > >=20 > > > > > a=20 > > > > > runtime value of the memory order (not that it would be of much= =20 > use=20 > > > > > though).=20 > > > > >=20 > > > > > I understand this would have consequences on the ABI because=20 > constexpr=20 > > > > > arguments essentiall require to duplicate the function body for= =20 > each=20 > > > > > constant=20 > > > > > argument value. It's not a big problem though because we already= =20 > do=20 > > >=20 > > > that=20 > > >=20 > > > > > for=20 > > > > > non-type template parameters.=20 > > > > >=20 > > > > > Opinions?=20 > > --=20 ---=20 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 e= mail 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-proposa= ls/. ------=_Part_300_7672864.1428852891915 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 12 =D0=B0=D0= =BF=D1=80=D0=B8=D0=BB 2015 =D0=B3., 17:16:09 UTC+3, Andrey Semashev =D0=BD= =D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
On Sunday 12 April 2015 06:13:35 Alexander Marinov wrote:
> You read my proposal - it does the same thing you want even if you= don't
> fully understand it.

I did read it, and I still don't think it covers my case. In fact, I'm = not=20
sure I agree with your proposal.

> Actually 'constexpr' is a useless keyword - it adds nothing to 'in= line'
> functions which most compilers already optimize out and evaluate a= t
> compile-time if possible.

It adds a _requirement_ on the function to be evaluated at compile time= ,=20
provided that its arguments are also constexpr. It also adds certain=20
restrictions on the function body. There is no such requirement or=20
restrictions for inline functions, and in fact even the most trivial in= line=20
functions are allowed to not be inlined or optimized. And this is the c= ase in=20
debug builds, for instance, when compilers don't do any inlining at all= but=20
are still bound to evaluate constexpr at compile time.

Actually it doesn't, neither 'constexp= r' do. A call to 'constexpr' is done the same way to a normal function so i= t's still a compiler decision if it's going to evaluate it at compile-time.= The only case where this is required is when such function is instanced at= place where constant-expression is expected. I don't see any reason not to= implicitly enable this feature to 'inline' functions too. Actually 'conste= xpr' functions are inline by default. Examples of current standard:

=
constexpr /*imagine < this was not there */ inline int func(int a= ) <= span style=3D"color: #660;" class=3D"styled-by-prettify">{ return a * 4; = }

//note the above declaration= is the same if 'inline' was not there because it's implicitly implied by '= constexpr'=

in= t b= ;

int main(){
    float arr[func(b)]; //here 'func' should be = evaluated at compile-time but this is currently not possible - error=


 = ;   i= nt runtime= =3D func(b); //ok, here 'func(b)' is evaluated at 'run-time'=


 = ;   f= loat arr1<= /span>[func(9)]; //ok, here 'func(b)' is evaluated at 'compile-time'

  &nbs= p; int compilerdec <= /span>=3D<= span style=3D"color: #000;" class=3D"styled-by-prettify"> func(9); //ok, here 'func(b)' is evaluated either at 'run-time' or = 'compile-time'

}

Note that the above = is a real working example. You can test it online here.

A= bout the function requirements - I really think that they are decided on no= real basis and I that they should be removed all. At first 'constexpr' fun= ction should consist only of a return statement, later this requirement was= lifted. I think now it's high-time to lift them all.
 

What you're suggesting is essentially mandate a certain level of compil= er=20
optimization as a language feature. I'm not sure this is a good idea.

> The part which fulfill your idea is 'inline' variables which are g= uaranteed
> to be evaluated at run-time (as template parameters)

I assume, you meant "compile-time" here?

Yeah - sorry - common mistake of mine.=
 

> and more specially
> 'inline' function parameters (which imply that the function they
> declare/define is 'inline' because templates can't be defined at d= ifferent
> TU).
>=20
> So your example will look like this by using my construct:
>=20
> template< typename T >
>   void atomic<T>::store(T val, inline memory_order orde= r)
>   {
>     switch (order) // order is always constexpr
>     {
>       // implementations with different memory orde= ring guarantees
>     }
>=20
>   }
>=20
> With the exact same semantics you want. Function parameter 'order'= will
> accept only constant-expressions and it will be evaluated at compi= le-time.

Yes, that would be my proposal, although I would still use constexpr ke= yword.=20
I didn't find inline variables in your proposal thread, sorry if I miss= ed it.

Why polite the source code with anothe= r new keyword as we can reuse an existing one.
 

> Actually those semantics are possible now too but have different
> syntax(etc. by using template parameters):
>=20
> template< typename T, memory_order order >
>   void atomic<T>::store(T val)
>   {
>     switch (order) // order is always constexpr
>     {
>       // implementations with different memory orde= ring guarantees
>     }
>=20
>   }

Sure. In fact, I would have defined std::atomic interface this way myse= lf in=20
the first place. I guess, we have it defined the way it is to support C= -style=20
interface? Anyway, we have what we have, and my proposal attempts to im= prove=20
it.

> =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 12 =D0=B0=D0=BF=D1=80=D0=B8= =D0=BB 2015 =D0=B3., 15:29:21 UTC+3, Andrey Semashev =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0:
> > On Sunday 12 April 2015 05:09:29 Alexander Marinov wrote:
> > > I already sketched the details of this idea. You can rea= d it here
> > > <
> >=20
> > https:/= /groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/RTss7= Uy
> > l
> >=20
> > > zgQ>. Only someone needs to write a proposal and/or i= mplement it as a
> >=20
> > demo
> >=20
> > > in some open-source compiler (GCC or Clang).
> >=20
> > No, I don't think your proposal is related to my idea. I'm no= t trying to
> > make
> > a function constexpr, I'm trying to propagate compile-time na= ture of some
> > of
> > its arguments to its body, which is executed in run time.
> >=20
> > (offtopic: And I do think that inline and constexpr are diffe= rent
> > properties
> > of the code, even though they are somewhat related on the imp= lementation
> > side;
> > I do not think they should be mixed together in a single keyw= ord.)
> >=20
> > > =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 12 =D0=B0=D0=BF=D1= =80=D0=B8=D0=BB 2015 =D0=B3., 13:33:17 UTC+3, Andrey Semashev =D0=BD=D0=B0= =D0=BF=D0=B8=D1=81=D0=B0:
> > > > Hi,
> > > >=20
> > > > I wonder if constexpr function arguments would be a= useful addition to
> >=20
> > the
> >=20
> > > > standard. Consider this part of std::atomic interfa= ce:
> > > >   template< typename T >
> > > >   void atomic<T>::store(T val, memory_or= der order)
> > > >   {
> > > >  =20
> > > >     switch (order)
> > > >     {
> > > >    =20
> > > >       // implementations with differ= ent memory ordering guarantees
> > > >    =20
> > > >     }
> > > >  =20
> > > >   }
> > > >=20
> > > > The function itself is not constexpr because the im= plementation has a
> > > > runtime
> > > > side effect. However the memory order argument is a= lways constant in
> > > > normal
> > > > uses and the implementation could have had benefitt= ed from knowing
> >=20
> > this
> >=20
> > > > constant at compile time. The current standard does= not offer means
> >=20
> > for
> >=20
> > > > that,
> > > > so you're out of luck if the compiler is not smart = enough to propagate
> > > > this
> > > > constexpr hint behind the scenes. For the most part= with compilers I
> >=20
> > have
> >=20
> > > > experience with (gcc, icl, msvc) this only works wh= en the compiler is
> >=20
> > able
> >=20
> > > > to
> > > > inline the function call.
> > > >=20
> > > > BTW, if anyone wonders if compiler intrinsics help = here, no they
> >=20
> > don't.
> >=20
> > > > With
> > > >=20
> > > > the code similar to this:
> > > >   template< typename T >
> > > >   void atomic<T>::store(T val, memory_or= der order)
> > > >   {
> > > >  =20
> > > >     __atomic_store_n(&m_value, val, o= rder);
> > > >  =20
> > > >   }
> > > >=20
> > > > gcc and icl simply fall back to memory_order_seq_cs= t regardless of the
> > > > specified order if they cannot inline the function.= This always
> >=20
> > happens in
> >=20
> > > > debug, for instance.
> > > >=20
> > > > What I'm thinking is if we could require some argum= ent to be constexpr
> >=20
> > and
> >=20
> > > > pass that 'compile-timeness' hint to the function b= ody, the
> >=20
> > implementation
> >=20
> > > > could optimize better. For example:
> > > >   template< typename T >
> > > >   void atomic<T>::store(T val, constexpr= memory_order order)
> > > >   {
> > > >  =20
> > > >     switch (order) // order is always con= stexpr
> > > >     {
> > > >    =20
> > > >       // implementations with differ= ent memory ordering guarantees
> > > >    =20
> > > >     }
> > > >  =20
> > > >   }
> > > >=20
> > > > In this case the switch/case would always be optimi= zed to a single
> >=20
> > case.
> >=20
> > > > And
> > > > the intrinsic-based version would also work as inte= nded. Also, if we
> >=20
> > have
> >=20
> > > > a
> > > > non-constexpr overload of this function we would al= so support calling
> >=20
> > with
> >=20
> > > > a
> > > > runtime value of the memory order (not that it woul= d be of much use
> > > > though).
> > > >=20
> > > > I understand this would have consequences on the AB= I because constexpr
> > > > arguments essentiall require to duplicate the funct= ion body for each
> > > > constant
> > > > argument value. It's not a big problem though becau= se we already do
> >=20
> > that
> >=20
> > > > for
> > > > non-type template parameters.
> > > >=20
> > > > Opinions?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_300_7672864.1428852891915-- ------=_Part_299_1292937151.1428852891915-- .