220 29574 <591447c7-38cd-4ad4-83aa-fc1326c1829e@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: "A Proposal to Relax Constexpr Restrictions for some Reinterpret Casts" ? Date: Mon, 28 Nov 2016 18:07:57 -0800 (PST) Lines: 133 Approved: news@gmane.org Message-ID: <591447c7-38cd-4ad4-83aa-fc1326c1829e@isocpp.org> References: <14dc989b-7a2f-478b-b16e-b9297fb1782f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_13345_1176416860.1480385277639" X-Trace: blaine.gmane.org 1480385287 16920 195.159.176.226 (29 Nov 2016 02:08:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 29 Nov 2016 02:08:07 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB7WF6PAQKGQERJHVLAY@isocpp.org Tue Nov 29 03:08:03 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f200.google.com ([209.85.223.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cBXpw-0002NL-GW for gclcip-std-proposals@m.gmane.org; Tue, 29 Nov 2016 03:08:00 +0100 Original-Received: by mail-io0-f200.google.com with SMTP id r101sf274897692ioi.3 for ; Mon, 28 Nov 2016 18:07:59 -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=DgCOvif3oc4Bv4oCR3tyQlJIDjaf/uaedUdtTERS8T8=; b=SAIoX8XP0k/g7RWpAI1XorwbMnTX6rG2yhEAbaoAFY9ksjusXkcZh3VJmS/u/1ApxF voxt0uoIiXdoVucy/XWcyn8FKLkcE4v4ueTcWj5FntrrOTtIyFShkb0tDKp2Hg8nod8v F+GIt6CEGag/IKgj+BUMm2o7RhwUEuVMcCIUcyLscGYS/zZDVrBo7i1+/hZr/eMzStg9 n310phaIC+qmu/wuJWqTNfgn6bE+WJMKDBRzs7QGRlx2C8q6bUQmqqlcMqa+3yOBXVXv b0ryChN8A2Vh9Ywj2ggMcTsuV2f1HJRStph5PTAYE2YbF2dsdnFgJ3oR0sWEgXt8YN05 69LA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=DgCOvif3oc4Bv4oCR3tyQlJIDjaf/uaedUdtTERS8T8=; b=VTaAnH2yQk69hKaPrJJsMXObHPL2ZpWDNqbWio/cRVllfEWoinOhtxcvfVzky8xrB4 BE1pms7HUPsxVRPRi2JQS+g85MDOT2ZfBTIx1ARJJTnmN2SEyRnjF83AR1VdRHS1UzWA mUX1kaz+n7XlAJcLbAlrqiduqmynyPHBr+5zvWJfMaNyQYgmpD/j8vc7Hc0NWUc1utDe N9Q2MXXhmsJFIGwEGy1ETVGoPwKDRvtPESOLS971cT4zYTa+aPMM8xBacWnSFHBER2eP 2gvCn/GVa+vkQmDAK8Zla/61yl3oUyLGA1e1Ssq2mwZEnAzZihiolsdV5JZQWxUFWdSI DxVQ== 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: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=DgCOvif3oc4Bv4oCR3tyQlJIDjaf/uaedUdtTERS8T8=; b=lSgeLQLizFf5XTMkAWkiNimwuptz1V4N4uGjEULiCVU7CxDQEk14uIO0ZB2a+eyk48 8uBiI/RJa/yJiQZPTymSkzjpuCId4C9BssuaQGPL/JSnGw2RlSLqClIpe0TtIRxrGf04 R+Rtq6unFxffeSlHyclMSgdf40AzyenbGr8iX3rHJzXgFplDBhoFvXKZ35vPU5e5Ey// fhgoQGQxkb+Q75zmbZCJtlT3vLiUUhWi99RPs4T/Kd0XRIzozOnvYuSSBiVwDswhsgGl 6OXHe1s2joNdYPBOMWUDtMQiRlDSUuyRtKLsYaAqzqEdd2G0pIKeujK9TG3Kv7Vft2vt BR7A== X-Gm-Message-State: AKaTC02T+Iw3FCysSrk8KjCcxtqFhA6SfVxxSx1Xj4RM91WZykFPSmwfIiJxLaJfLcA0ig== X-Received: by 10.107.162.69 with SMTP id l66mr4790354ioe.70.1480385278958; Mon, 28 Nov 2016 18:07:58 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.3.145 with SMTP id f17ls12304713otf.27.gmail; Mon, 28 Nov 2016 18:07:58 -0800 (PST) X-Received: by 10.157.17.3 with SMTP id g3mr781845ote.8.1480385278251; Mon, 28 Nov 2016 18:07:58 -0800 (PST) In-Reply-To: X-Original-Sender: jmckesson@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:29574 Archived-At: ------=_Part_13345_1176416860.1480385277639 Content-Type: multipart/alternative; boundary="----=_Part_13346_2096209644.1480385277640" ------=_Part_13346_2096209644.1480385277640 Content-Type: text/plain; charset=UTF-8 On Monday, November 28, 2016 at 7:01:39 PM UTC-5, Richard Smith wrote: > > On 28 November 2016 at 15:00, 'Edward Catmur' via ISO C++ Standard - > Future Proposals > wrote: > >> On 28 Nov 2016 22:50, "Peet Nick" > >> wrote: >> > >> > Ah, I understand. Although I understand this now, I am not entirely >> sure how it will be actually implemented. How would someone implement >> bit_cast as a constexpr without having std::memcpy constexpr? >> >> They'd have to use a compiler intrinsic; according to [1] llvm already >> has a suitable opcode, >> > That doesn't help at all. Constant expression evaluation happens at a > completely different layer from LLVM. > > memcpy is fundamentally not possible to support in general within constant > expression evaluation; consider: > > int n; > constexpr int *p = &n; // ok > constexpr intptr_t q = bit_cast(p); // ok? > static_assert(q > 0x1234567); // ok?! > > Clearly this example must be ill-formed. But either that means you can't > do the bit_cast in a constant expression or that you can evaluate an > integer as part of a constant expression that you then can't do basic > integer operations on. > This is *precisely* why `bit_cast` is a good thing. Because it's a function which knows both the source and destination types, we would be able to say that it is `constexpr` when doing certain conversions and not `constexpr` when doing others. For example, any conversion of a pointer to anything other than a pointer would not be `constexpr`. This would include within various types, so you couldn't have a `struct{int *p};` that you `bit_cast` to a `struct{intptr_t q};`. The OP asked specifically about converting integers to their bit-representation to do hashing and so forth. `bit_cast` could be `constexpr` for such operations. So there's no problem. -- 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/591447c7-38cd-4ad4-83aa-fc1326c1829e%40isocpp.org. ------=_Part_13346_2096209644.1480385277640 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Monday, November 28, 2016 at 7:01:39 PM UTC-5, = Richard Smith wrote:
On 28 November 2016 at 15:00, '= ;Edward Catmur' via ISO C++ Standard - Future Proposals <

On 28 Nov 2016 22:50, "Peet Nick" <peet...@gmail.com= > wrote:
>
> Ah, I understand. Although I understand this now, I am not entirely su= re how it will be actually implemented. How would someone implement bit_cas= t as a constexpr without having std::memcpy constexpr?

They'd have to use a compiler intrinsic; accordin= g to [1] llvm already has a suitable opcode,

That does= n't help at all. Constant expression evaluation happens at a completely= different layer from LLVM.

memcpy is fundamentall= y not possible to support in general within constant expression evaluation;= consider:

=C2=A0 int n;
=C2=A0 cons= texpr int *p =3D &n; // ok
=C2=A0 constexpr intptr_t q =3D bi= t_cast<intptr_t>(p); // ok?
=C2=A0 static_assert(q > 0x1= 234567); // ok?!

Clearly this example must be ill-for= med. But either that means you can't do the bit_cast in a constant expr= ession or that you can evaluate an integer as part of a constant expression= that you then can't do basic integer operations on.
<= /div>

This is precisely why `bit_cast` is a goo= d thing. Because it's a function which knows both the source and destin= ation types, we would be able to say that it is `constexpr` when doing=20 certain conversions and not `constexpr` when doing others. For example,=20 any conversion of a pointer to anything other than a pointer would not=20 be `constexpr`. This would include within various types, so you couldn'= t have a `struct{int *p};` that you `bit_cast` to a `struct{intptr_t=20 q};`.

The OP asked specifically about converting integers to=20 their bit-representation to do hashing and so forth. `bit_cast` could be `constexpr` for such operations.

So there's no problem.

--
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/591447c7-38cd-4ad4-83aa-fc1326c1829e= %40isocpp.org.
------=_Part_13346_2096209644.1480385277640-- ------=_Part_13345_1176416860.1480385277639-- .