220 22206 article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Local constexpr variables and static storage duration Date: Tue, 3 Nov 2015 11:52:46 +0800 Lines: 148 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_68B7EC1D-4C98-40B9-AEE9-001B160471B5" X-Trace: ger.gmane.org 1446522783 14707 80.91.229.3 (3 Nov 2015 03:53:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Nov 2015 03:53:03 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBGG74CYQKGQEX3772VA@isocpp.org Tue Nov 03 04:52:59 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f199.google.com ([209.85.213.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZtSeY-0005J4-2v for gclcip-std-proposals@m.gmane.org; Tue, 03 Nov 2015 04:52:58 +0100 Original-Received: by igbxf8 with SMTP id xf8sf15151340igb.1 for ; Mon, 02 Nov 2015 19:52:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-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=326PZoHfOEUGk/rQ5lRF4Q34yxSU2dOqX8iU7YDB/pg=; b=EhJvnWJ+1ZwQM98tgk5KyU9bFvCTjZKQwHv5g81wy/yjHxOrVoUWkFXpjJxHFn9PYj PyqKj2P8WxeL4ZMebxKQfNqsmpoDOGFurLePsnFSW49Iz8jYfNJmCZW1RHGc6H/ApQlr pEj/qUJIqPgC/Tq0Ji8kjgaGsccms0Q/zJ/io1nSZihV+pXMCoANvYTb1jLNPDb98UTC t/UH+6X49c9v5y1MYp+iPEQR3+so2ws+MjlI+8yhfKmMCpFF2YMqX5kJdMuPT4Um9teE SFaZOZ8SGhU7yfeKVqsiP4+weXRQxB0DSJvMLky3FJHCS9aENo6jENTm/SIcQTJYXqKY EhMw== X-Gm-Message-State: ALoCoQl2BtVhiuKAz0LEkx/oRK514iv4Z9JvetpoL+kg9CORRoaBU+n5ejnq2rCVXpiKc691lSEY X-Received: by 10.182.230.197 with SMTP id ta5mr21200812obc.37.1446522777011; Mon, 02 Nov 2015 19:52:57 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.33.80 with SMTP id h77ls1607691ioh.79.gmail; Mon, 02 Nov 2015 19:52:56 -0800 (PST) X-Received: by 10.66.246.162 with SMTP id xx2mr30798368pac.144.1446522775998; Mon, 02 Nov 2015 19:52:55 -0800 (PST) Original-Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com. [2607:f8b0:400e:c03::22c]) by mx.google.com with ESMTPS id yk5si39873564pbc.199.2015.11.02.19.52.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 19:52:55 -0800 (PST) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c03::22c as permitted sender) client-ip=2607:f8b0:400e:c03::22c; Original-Received: by pasz6 with SMTP id z6so5878516pas.2 for ; Mon, 02 Nov 2015 19:52:55 -0800 (PST) X-Received: by 10.69.1.9 with SMTP id bc9mr29733668pbd.128.1446522775717; Mon, 02 Nov 2015 19:52:55 -0800 (PST) Original-Received: from [172.20.10.2] ([121.54.44.90]) by smtp.gmail.com with ESMTPSA id qy7sm26793462pab.37.2015.11.02.19.52.52 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 02 Nov 2015 19:52:55 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.2104) X-Original-Sender: potswa@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c03::22c as permitted sender) smtp.mailfrom=potswa@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:22206 Archived-At: --Apple-Mail=_68B7EC1D-4C98-40B9-AEE9-001B160471B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 > On 2015=E2=80=9311=E2=80=9303, at 6:04 AM, Columbo wrote: >=20 > Is it possible to let local variables declared with constexpr have static= storage duration? Since every constexpr variables's initializer can neithe= r depend upon parameter values nor dynamically initialized (or modifiable) = global state, they may as well have static storage duration with static ini= tialization AFAICS. =20 Static storage and initialization aren=E2=80=99t necessarily better. The sc= heme uses less space while a function is recursing (it has at least two act= ive stack frames), but potentially more space when it=E2=80=99s not executi= ng. It may also reduce cache locality. > Would that introduce any problems or have significant impacts? It would violate object uniqueness. On the other hand, this is an area where some flexibility might be found. A= lready, sequence elements in std::initializer_list arrays are de-facto not = guaranteed uniqueness. If it=E2=80=99s treated as an optional optimization = (outside the as-if rule) instead of a requirement, then your proposal more= -or-less comes down to allocating constexpr local variables as if they were= inside initializer lists. Separately but similarly, I think it would be nice to un-uniquefy all prval= ue expressions (except when bound to non-const references). In any case, I= =E2=80=99m not aware of much practical value to static storage outside of l= arge tables. This is the problem domain of initializer_list, however, it ha= s its own issues. > Note that it would allow reasonable things that are currently disallowed,= e.g. > void f() { > constexpr int arr[] {1, 2, 3};=20 > constexpr auto p =3D arr; > } This works on GCC: constexpr std::initializer_list< int > il =3D { 1, 2, 3 }; constexpr int const * p =3D il.begin(); Clang rejects this, I guess because the initializer_list stores a pointer t= o the first element of the array and not a pointer to the entire array obje= ct, and because it validates the =E2=80=9Cpermitted result of a constant ex= pression=E2=80=9D rule before applying the static storage optimization. I t= hink that both are conforming, or at least, GCC is being reasonable :P . Of course, for cases such as this where static storage is required, you sho= uld simply declare the variable as static. With that adjustment, both of ou= r examples work portably. --=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/. --Apple-Mail=_68B7EC1D-4C98-40B9-AEE9-001B160471B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
On 2015=E2=80=9311= =E2=80=9303, at 6:04 AM, Columbo <r.hl@gmx.net> wrote:

Is it possible to let local= variables declared with constexpr have static storage duration? Since every constexpr variables's i= nitializer can neither depend upon parameter values nor dynamically initial= ized (or modifiable) global state, they may as well have static storage dur= ation with static initialization AFAICS.  

Static storage and initialization aren=E2=80=99= t necessarily better. The scheme uses less space while a function is recurs= ing (it has at least two active stack frames), but potentially more space w= hen it=E2=80=99s not executing. It may also reduce cache locality.
Would that introduce any problems or have significant i= mpacts?

It would vio= late object uniqueness.

On the other ha= nd, this is an area where some flexibility might be found. Already, sequenc= e elements in std::initializer_list arrays are de-facto not guaranteed uniqueness. If it=E2=80=99s treated as= an optional optimization (outside the as-if rule) instead of a requirement= ,  then your proposal more-or-less comes down to allocating constexpr = local variables as if they were inside initializer lists.

Separately but similarly, I think it would be nice to un= -uniquefy all prvalue expressions (except when bound to non-const reference= s). In any case, I=E2=80=99m not aware of much practical value to static st= orage outside of large tables. This is the problem domain of initializer_list, however, it has its own i= ssues.

=
Note that it would allow reaso= nable things that are currently disallowed, e.g.
void f() {
    constexp= r int arr[] {1, 2, 3}; 
  &nbs= p; constexpr auto p =3D arr;
}

This works on GCC:

constexpr std::initializer_list< int > il =3D { 1, 2= , 3 };
constexpr int con= st * p =3D il.begin();

Clang= rejects this, I guess because the initializer_list stores a pointer to the first el= ement of the array and not a pointer to the entire array object, and becaus= e it validates the =E2=80=9Cpermitted result of a constant expression=E2=80= =9D rule before applying the static storage optimization. I think that both= are conforming, or at least, GCC is being reasonable :P .
<= br class=3D"">
Of course, for cases such as this where static sto= rage is required, you should simply declare the variable as static. With that adjustment, both of our example= s work portably.

--

---
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>.
--Apple-Mail=_68B7EC1D-4C98-40B9-AEE9-001B160471B5-- .