Topic: A Proposal to Relax Constexpr Restrictions for
Author: Mathias Gaunard <mathias@gaunard.com>
Date: Fri, 25 Nov 2016 15:32:47 +0000
Raw View
--089e0122814292b88e054221d576
Content-Type: text/plain; charset=UTF-8
I think you would have better luck with the new function bit_cast which
might end up being constexpr.
On 25 November 2016 at 11:32, Peet <peetnick2@gmail.com> wrote:
> Hello,
>
> I was basically trying to implement a hash function in C++ using constant
> expressions (constexpr).
> Sometimes it is necessary to cast a scalar type (or arrays) to cv
> unsigned/signed char* to simply get the bytes and do some calculation.
> Although it seems that reinterpret_casts aren't allowed in constexpr
> (5.20/2.14).
> Quickly googling this issue got me to this proposal: "A Proposal to Relax
> Constexpr Restrictions for some Reinterpret Casts" by Antony Polukhin [1].
> This proposal relaxes the rule for reinterpret_cast in constexpr so that
> we can actually cast cv void* to cv unsigned/signed char*.
> Although I couldn't find any discussions about this online, also it seems
> that the proposal hasn't been sent to the openstd mailing-list.
> Does anyone know if this proposal is still "alive" and if this is being
> considered proposing?
>
> Regards,
> Nick
>
> [1] https://apolukhin.github.io/constexpr_algorithms/reinterpret.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/afbaf79e-305d-4408-
> 98ab-5b35cfb11f27%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/afbaf79e-305d-4408-98ab-5b35cfb11f27%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALnjya_VWQUMYGGd9tYy_cJWiwvsyUF2joMuCMPsPy%3DT6e15XA%40mail.gmail.com.
--089e0122814292b88e054221d576
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think you would have better luck with the new function b=
it_cast which might end up being constexpr.</div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On 25 November 2016 at 11:32, Peet <span di=
r=3D"ltr"><<a href=3D"mailto:peetnick2@gmail.com" target=3D"_blank">peet=
nick2@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">Hello,<div><br></div><div>I was basically trying to implement=
a hash function in C++ using constant expressions (constexpr).</div><div>S=
ometimes it is necessary to cast a scalar type (or arrays) to cv unsigned/s=
igned char* to simply get the bytes and do some calculation.</div><div>Alth=
ough it seems that reinterpret_casts aren't allowed in constexpr (5.20/=
2.14).</div><div>Quickly googling this issue got me to this proposal:=C2=A0=
"A Proposal to Relax Constexpr Restrictions for some Reinterpret Casts=
" by=C2=A0Antony Polukhin [1].</div><div>This proposal relaxes the rul=
e for reinterpret_cast in constexpr so that we can actually cast cv void* t=
o cv unsigned/signed char*.</div><div>Although I couldn't find any disc=
ussions about this online, also it seems that the proposal hasn't been =
sent to the openstd mailing-list.</div><div>Does anyone know if this propos=
al is still "alive" and if this is being considered proposing?</d=
iv><div><br></div><div>Regards,</div><div>Nick</div><div><br></div><div>[1]=
=C2=A0<a href=3D"https://apolukhin.github.io/constexpr_algorithms/reinterpr=
et.html" target=3D"_blank">https://apolukhin.github.<wbr>io/constexpr_algor=
ithms/<wbr>reinterpret.html</a></div></div><span class=3D"HOEnZb"><font col=
or=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/afbaf79e-305d-4408-98ab-5b35cfb11f27%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/afba=
f79e-305d-4408-<wbr>98ab-5b35cfb11f27%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya_VWQUMYGGd9tYy_cJWiwvsyUF2joMu=
CMPsPy%3DT6e15XA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya_VWQUMYG=
Gd9tYy_cJWiwvsyUF2joMuCMPsPy%3DT6e15XA%40mail.gmail.com</a>.<br />
--089e0122814292b88e054221d576--
.
Author: Peet Nick <peetnick2@gmail.com>
Date: Mon, 28 Nov 2016 23:04:39 +0100
Raw View
--089e0102e15e7dd374054263a876
Content-Type: text/plain; charset=UTF-8
I am not sure how that would help? The destination type must have the same
size as the source type, how would that help me getting the "raw byte view"
of an scalar/pod?
On Fri, Nov 25, 2016 at 4:32 PM, Mathias Gaunard <mathias@gaunard.com>
wrote:
> I think you would have better luck with the new function bit_cast which
> might end up being constexpr.
>
> On 25 November 2016 at 11:32, Peet <peetnick2@gmail.com> wrote:
>
>> Hello,
>>
>> I was basically trying to implement a hash function in C++ using constant
>> expressions (constexpr).
>> Sometimes it is necessary to cast a scalar type (or arrays) to cv
>> unsigned/signed char* to simply get the bytes and do some calculation.
>> Although it seems that reinterpret_casts aren't allowed in constexpr
>> (5.20/2.14).
>> Quickly googling this issue got me to this proposal: "A Proposal to Relax
>> Constexpr Restrictions for some Reinterpret Casts" by Antony Polukhin [1].
>> This proposal relaxes the rule for reinterpret_cast in constexpr so that
>> we can actually cast cv void* to cv unsigned/signed char*.
>> Although I couldn't find any discussions about this online, also it seems
>> that the proposal hasn't been sent to the openstd mailing-list.
>> Does anyone know if this proposal is still "alive" and if this is being
>> considered proposing?
>>
>> Regards,
>> Nick
>>
>> [1] https://apolukhin.github.io/constexpr_algorithms/reinterpret.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/is
>> ocpp.org/d/msgid/std-proposals/afbaf79e-305d-4408-98ab-
>> 5b35cfb11f27%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/afbaf79e-305d-4408-98ab-5b35cfb11f27%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> 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/CALnjya_VWQUMYGGd9tYy_
> cJWiwvsyUF2joMuCMPsPy%3DT6e15XA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya_VWQUMYGGd9tYy_cJWiwvsyUF2joMuCMPsPy%3DT6e15XA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAJwqTS9XiyDK%2B7wWCRTCTjcnFnKQk6WudsrRTidgf4Ygoc0yng%40mail.gmail.com.
--089e0102e15e7dd374054263a876
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I am not sure how that would help? The destination type mu=
st have the same size as the source type, how would that help me getting th=
e "raw byte view" of an scalar/pod?</div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Fri, Nov 25, 2016 at 4:32 PM, Mathias =
Gaunard <span dir=3D"ltr"><<a href=3D"mailto:mathias@gaunard.com" target=
=3D"_blank">mathias@gaunard.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">I think you would have better luck with the =
new function bit_cast which might end up being constexpr.</div><div><div cl=
ass=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 25 =
November 2016 at 11:32, Peet <span dir=3D"ltr"><<a href=3D"mailto:peetni=
ck2@gmail.com" target=3D"_blank">peetnick2@gmail.com</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello,<div><br></div><di=
v>I was basically trying to implement a hash function in C++ using constant=
expressions (constexpr).</div><div>Sometimes it is necessary to cast a sca=
lar type (or arrays) to cv unsigned/signed char* to simply get the bytes an=
d do some calculation.</div><div>Although it seems that reinterpret_casts a=
ren't allowed in constexpr (5.20/2.14).</div><div>Quickly googling this=
issue got me to this proposal:=C2=A0"A Proposal to Relax Constexpr Re=
strictions for some Reinterpret Casts" by=C2=A0Antony Polukhin [1].</d=
iv><div>This proposal relaxes the rule for reinterpret_cast in constexpr so=
that we can actually cast cv void* to cv unsigned/signed char*.</div><div>=
Although I couldn't find any discussions about this online, also it see=
ms that the proposal hasn't been sent to the openstd mailing-list.</div=
><div>Does anyone know if this proposal is still "alive" and if t=
his is being considered proposing?</div><div><br></div><div>Regards,</div><=
div>Nick</div><div><br></div><div>[1]=C2=A0<a href=3D"https://apolukhin.git=
hub.io/constexpr_algorithms/reinterpret.html" target=3D"_blank">https://apo=
lukhin.github.i<wbr>o/constexpr_algorithms/reinter<wbr>pret.html</a></div><=
/div><span class=3D"m_304883840893532982HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/afbaf79e-305d-4408-98ab-5b35cfb11f27%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/afba=
f79e-305d-4408-98ab-<wbr>5b35cfb11f27%40isocpp.org</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya_VWQUMYGGd9tYy_cJWiwvsyUF2joMu=
CMPsPy%3DT6e15XA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CALnjya_<wbr>VWQUMYGGd9tYy_<wbr>cJWiwvsyUF2joMuCMPsPy%<wbr=
>3DT6e15XA%40mail.gmail.com</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJwqTS9XiyDK%2B7wWCRTCTjcnFnKQk6Wuds=
rRTidgf4Ygoc0yng%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJwqTS9XiyDK%2=
B7wWCRTCTjcnFnKQk6WudsrRTidgf4Ygoc0yng%40mail.gmail.com</a>.<br />
--089e0102e15e7dd374054263a876--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Mon, 28 Nov 2016 14:35:37 -0800 (PST)
Raw View
------=_Part_11810_967191564.1480372537100
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, 28 November 2016 22:04:42 UTC, Peet Nick wrote:
> I am not sure how that would help? The destination type must have the sam=
e size as the source type, how would that help me getting the "raw byte vie=
w" of an scalar/pod?
You would bit_cast to an array (or std::array) of unsigned char of the same=
size as your pod.=20
> On Fri, Nov 25, 2016 at 4:32 PM, Mathias Gaunard <mat...@gaunard.com> wro=
te:
>=20
> I think you would have better luck with the new function bit_cast which m=
ight end up being constexpr.
>=20
>=20
>=20
>=20
> On 25 November 2016 at 11:32, Peet <peet...@gmail.com> wrote:
>=20
> Hello,
>=20
>=20
> I was basically trying to implement a hash function in C++ using constant=
expressions (constexpr).
> Sometimes it is necessary to cast a scalar type (or arrays) to cv unsigne=
d/signed char* to simply get the bytes and do some calculation.
> Although it seems that reinterpret_casts aren't allowed in constexpr (5.2=
0/2.14).
> Quickly googling this issue got me to this proposal:=C2=A0"A Proposal to =
Relax Constexpr Restrictions for some Reinterpret Casts" by=C2=A0Antony Pol=
ukhin [1].
> This proposal relaxes the rule for reinterpret_cast in constexpr so that =
we can actually cast cv void* to cv unsigned/signed char*.
> Although I couldn't find any discussions about this online, also it seems=
that the proposal hasn't been sent to the openstd mailing-list.
> Does anyone know if this proposal is still "alive" and if this is being c=
onsidered proposing?
>=20
>=20
> Regards,
> Nick
>=20
>=20
> [1]=C2=A0https://apolukhin.github.io/constexpr_algorithms/reinterpret.htm=
l
>=20
>=20
>=20
>=20
> --=20
>=20
> You received this message because you are subscribed to the Google Groups=
"ISO C++ Standard - Future Proposals" group.
>=20
> To unsubscribe from this group and stop receiving emails from it, send an=
email to std-proposal...@isocpp.org.
>=20
> To post to this group, send email to std-pr...@isocpp.org.
>=20
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/afbaf79e-305d-4408-98ab-5b35cfb11f27%40isocpp.=
org.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> --=20
>=20
> You received this message because you are subscribed to the Google Groups=
"ISO C++ Standard - Future Proposals" group.
>=20
> To unsubscribe from this group and stop receiving emails from it, send an=
email to std-proposal...@isocpp.org.
>=20
> To post to this group, send email to std-pr...@isocpp.org.
>=20
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/CALnjya_VWQUMYGGd9tYy_cJWiwvsyUF2joMuCMPsPy%3D=
T6e15XA%40mail.gmail.com.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/14dc989b-7a2f-478b-b16e-b9297fb1782f%40isocpp.or=
g.
------=_Part_11810_967191564.1480372537100--
.
Author: Peet Nick <peetnick2@gmail.com>
Date: Mon, 28 Nov 2016 23:50:33 +0100
Raw View
--001a114717b6a4b0f60542644c2a
Content-Type: text/plain; charset=UTF-8
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?
On Mon, Nov 28, 2016 at 11:35 PM, Edward Catmur <ed@catmur.co.uk> wrote:
> On Monday, 28 November 2016 22:04:42 UTC, Peet Nick wrote:
> > I am not sure how that would help? The destination type must have the
> same size as the source type, how would that help me getting the "raw byte
> view" of an scalar/pod?
>
> You would bit_cast to an array (or std::array) of unsigned char of the
> same size as your pod.
>
> > On Fri, Nov 25, 2016 at 4:32 PM, Mathias Gaunard <mat...@gaunard.com>
> wrote:
> >
> > I think you would have better luck with the new function bit_cast which
> might end up being constexpr.
> >
> >
> >
> >
> > On 25 November 2016 at 11:32, Peet <peet...@gmail.com> wrote:
> >
> > Hello,
> >
> >
> > I was basically trying to implement a hash function in C++ using
> constant expressions (constexpr).
> > Sometimes it is necessary to cast a scalar type (or arrays) to cv
> unsigned/signed char* to simply get the bytes and do some calculation.
> > Although it seems that reinterpret_casts aren't allowed in constexpr
> (5.20/2.14).
> > Quickly googling this issue got me to this proposal: "A Proposal to
> Relax Constexpr Restrictions for some Reinterpret Casts" by Antony Polukhin
> [1].
> > This proposal relaxes the rule for reinterpret_cast in constexpr so that
> we can actually cast cv void* to cv unsigned/signed char*.
> > Although I couldn't find any discussions about this online, also it
> seems that the proposal hasn't been sent to the openstd mailing-list.
> > Does anyone know if this proposal is still "alive" and if this is being
> considered proposing?
> >
> >
> > Regards,
> > Nick
> >
> >
> > [1] https://apolukhin.github.io/constexpr_algorithms/reinterpret.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-proposal...@isocpp.org.
> >
> > To post to this group, send email to std-pr...@isocpp.org.
> >
> > To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/afbaf79e-305d-4408-
> 98ab-5b35cfb11f27%40isocpp.org.
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> > 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-proposal...@isocpp.org.
> >
> > To post to this group, send email to std-pr...@isocpp.org.
> >
> > To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CALnjya_VWQUMYGGd9tYy_
> cJWiwvsyUF2joMuCMPsPy%3DT6e15XA%40mail.gmail.com.
>
> --
> 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/14dc989b-7a2f-478b-
> b16e-b9297fb1782f%40isocpp.org.
>
--
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/CAJwqTS_OGEOUiUE6rSRrREV6Yx9%2B4Sj5gA8CDHeYgXnPwErW6Q%40mail.gmail.com.
--001a114717b6a4b0f60542644c2a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Ah, I understand. Although I understand this now, I am not=
entirely sure how it will be actually implemented. How would someone imple=
ment bit_cast as a constexpr without having std::memcpy constexpr?</div><di=
v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Nov 28, 2016=
at 11:35 PM, Edward Catmur <span dir=3D"ltr"><<a href=3D"mailto:ed@catm=
ur.co.uk" target=3D"_blank">ed@catmur.co.uk</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><span class=3D"">On Monday, 28 November 2016 22:04=
:42 UTC, Peet Nick=C2=A0 wrote:<br>
> I am not sure how that would help? The destination type must have the =
same size as the source type, how would that help me getting the "raw =
byte view" of an scalar/pod?<br>
<br>
</span>You would bit_cast to an array (or std::array) of unsigned char of t=
he same size as your pod.<br>
<span class=3D""><br>
> On Fri, Nov 25, 2016 at 4:32 PM, Mathias Gaunard <<a href=3D"mailto=
:mat...@gaunard.com">mat...@gaunard.com</a>> wrote:<br>
><br>
> I think you would have better luck with the new function bit_cast whic=
h might end up being constexpr.<br>
><br>
><br>
><br>
><br>
</span><span class=3D"">> On 25 November 2016 at 11:32, Peet <<a href=
=3D"mailto:peet...@gmail.com">peet...@gmail.com</a>> wrote:<br>
><br>
> Hello,<br>
><br>
><br>
> I was basically trying to implement a hash function in C++ using const=
ant expressions (constexpr).<br>
> Sometimes it is necessary to cast a scalar type (or arrays) to cv unsi=
gned/signed char* to simply get the bytes and do some calculation.<br>
> Although it seems that reinterpret_casts aren't allowed in constex=
pr (5.20/2.14).<br>
> Quickly googling this issue got me to this proposal:=C2=A0"A Prop=
osal to Relax Constexpr Restrictions for some Reinterpret Casts" by=C2=
=A0Antony Polukhin [1].<br>
> This proposal relaxes the rule for reinterpret_cast in constexpr so th=
at we can actually cast cv void* to cv unsigned/signed char*.<br>
> Although I couldn't find any discussions about this online, also i=
t seems that the proposal hasn't been sent to the openstd mailing-list.=
<br>
> Does anyone know if this proposal is still "alive" and if th=
is is being considered proposing?<br>
><br>
><br>
> Regards,<br>
> Nick<br>
><br>
><br>
> [1]=C2=A0<a href=3D"https://apolukhin.github.io/constexpr_algorithms/r=
einterpret.html" rel=3D"noreferrer" target=3D"_blank">https://apolukhin.git=
hub.<wbr>io/constexpr_algorithms/<wbr>reinterpret.html</a><br>
><br>
><br>
><br>
><br>
> --<br>
><br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
><br>
</span>> To unsubscribe from this group and stop receiving emails from i=
t, send an email to <a href=3D"mailto:std-proposal...@isocpp.org">std-propo=
sal...@isocpp.org</a>.<br>
><br>
> To post to this group, send email to <a href=3D"mailto:std-pr...@isocp=
p.org">std-pr...@isocpp.org</a>.<br>
<span class=3D"">><br>
> To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/afbaf79e-305d-4408-98ab-5b35cfb1=
1f27%40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.goog=
le.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/afbaf79e-305d-4408-<wbr=
>98ab-5b35cfb11f27%40isocpp.org</a><wbr>.<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
><br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
><br>
</span>> To unsubscribe from this group and stop receiving emails from i=
t, send an email to <a href=3D"mailto:std-proposal...@isocpp.org">std-propo=
sal...@isocpp.org</a>.<br>
><br>
> To post to this group, send email to <a href=3D"mailto:std-pr...@isocp=
p.org">std-pr...@isocpp.org</a>.<br>
<span class=3D"">><br>
> To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/CALnjya_VWQUMYGGd9tYy_cJWiwvsyUF=
2joMuCMPsPy%3DT6e15XA%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank=
">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CA=
Lnjya_<wbr>VWQUMYGGd9tYy_<wbr>cJWiwvsyUF2joMuCMPsPy%<wbr>3DT6e15XA%40mail.g=
mail.com</a>.<br>
<br>
</span><span class=3D"">--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/14dc989b-7a2f-478b-b16e-b9297f=
b1782f%40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.go=
ogle.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/14dc989b-7a2f-478b-<w=
br>b16e-b9297fb1782f%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJwqTS_OGEOUiUE6rSRrREV6Yx9%2B4Sj5gA=
8CDHeYgXnPwErW6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJwqTS_OGEOUiU=
E6rSRrREV6Yx9%2B4Sj5gA8CDHeYgXnPwErW6Q%40mail.gmail.com</a>.<br />
--001a114717b6a4b0f60542644c2a--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 28 Nov 2016 23:00:55 +0000
Raw View
--94eb2c070d62c45ee705426471e3
Content-Type: text/plain; charset=UTF-8
On 28 Nov 2016 22:50, "Peet Nick" <peetnick2@gmail.com> 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, so the other compilers would have to do the same, if
they don't have an appropriate intrinsic available already.
Remember, it's fine for library functions to need compiler magic to
implement; part of the job of the standard library is to provide
standardized interfaces to such magic.
1. http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0476r0.html
> On Mon, Nov 28, 2016 at 11:35 PM, Edward Catmur <ed@catmur.co.uk> wrote:
>>
>> On Monday, 28 November 2016 22:04:42 UTC, Peet Nick wrote:
>> > I am not sure how that would help? The destination type must have the
same size as the source type, how would that help me getting the "raw byte
view" of an scalar/pod?
>>
>> You would bit_cast to an array (or std::array) of unsigned char of the
same size as your pod.
>>
>> > On Fri, Nov 25, 2016 at 4:32 PM, Mathias Gaunard <mat...@gaunard.com>
wrote:
>> >
>> > I think you would have better luck with the new function bit_cast
which might end up being constexpr.
>> >
>> >
>> >
>> >
>> > On 25 November 2016 at 11:32, Peet <peet...@gmail.com> wrote:
>> >
>> > Hello,
>> >
>> >
>> > I was basically trying to implement a hash function in C++ using
constant expressions (constexpr).
>> > Sometimes it is necessary to cast a scalar type (or arrays) to cv
unsigned/signed char* to simply get the bytes and do some calculation.
>> > Although it seems that reinterpret_casts aren't allowed in constexpr
(5.20/2.14).
>> > Quickly googling this issue got me to this proposal: "A Proposal to
Relax Constexpr Restrictions for some Reinterpret Casts" by Antony Polukhin
[1].
>> > This proposal relaxes the rule for reinterpret_cast in constexpr so
that we can actually cast cv void* to cv unsigned/signed char*.
>> > Although I couldn't find any discussions about this online, also it
seems that the proposal hasn't been sent to the openstd mailing-list.
>> > Does anyone know if this proposal is still "alive" and if this is
being considered proposing?
>> >
>> >
>> > Regards,
>> > Nick
>> >
>> >
>> > [1] https://apolukhin.github.io/constexpr_algorithms/reinterpret.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-proposal...@isocpp.org.
>> >
>> > To post to this group, send email to std-pr...@isocpp.org.
>> >
>> > To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/afbaf79e-305d-4408-98ab-5b35cfb11f27%40isocpp.org
..
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> >
>> > 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-proposal...@isocpp.org.
>> >
>> > To post to this group, send email to std-pr...@isocpp.org.
>> >
>> > To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya_VWQUMYGGd9tYy_cJWiwvsyUF2joMuCMPsPy%3DT6e15XA%40mail.gmail.com
..
>>
>> --
>> 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/14dc989b-7a2f-478b-b16e-b9297fb1782f%40isocpp.org
..
>
>
> --
> You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/6tkocdbwVGU/unsubscribe
..
> To unsubscribe from this group and all its topics, 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/CAJwqTS_OGEOUiUE6rSRrREV6Yx9%2B4Sj5gA8CDHeYgXnPwErW6Q%40mail.gmail.com
..
--
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/CAJnLdOaJRPtdnHPX0%3DL89Pip2GC90aXrEYtJdUYxaHw1vwNJ%3Dw%40mail.gmail.com.
--94eb2c070d62c45ee705426471e3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"></p>
<p dir=3D"ltr">On 28 Nov 2016 22:50, "Peet Nick" <<a href=3D"m=
ailto:peetnick2@gmail.com">peetnick2@gmail.com</a>> wrote:<br>
><br>
> 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?</p>
<p dir=3D"ltr">They'd have to use a compiler intrinsic; according to [1=
] llvm already has a suitable opcode, so the other compilers would have to =
do the same, if they don't have an appropriate intrinsic available alre=
ady. </p>
<p dir=3D"ltr">Remember, it's fine for library functions to need compil=
er magic to implement; part of the job of the standard library is to provid=
e standardized interfaces to such magic. </p>
<p dir=3D"ltr">1. <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers=
/2016/p0476r0.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p04=
76r0.html</a></p>
<p dir=3D"ltr">> On Mon, Nov 28, 2016 at 11:35 PM, Edward Catmur <<a =
href=3D"mailto:ed@catmur.co.uk">ed@catmur.co.uk</a>> wrote:<br>
>><br>
>> On Monday, 28 November 2016 22:04:42 UTC, Peet Nick=C2=A0 wrote:<b=
r>
>> > I am not sure how that would help? The destination type must =
have the same size as the source type, how would that help me getting the &=
quot;raw byte view" of an scalar/pod?<br>
>><br>
>> You would bit_cast to an array (or std::array) of unsigned char of=
the same size as your pod.<br>
>><br>
>> > On Fri, Nov 25, 2016 at 4:32 PM, Mathias Gaunard <<a href=
=3D"mailto:mat...@gaunard.com">mat...@gaunard.com</a>> wrote:<br>
>> ><br>
>> > I think you would have better luck with the new function bit_=
cast which might end up being constexpr.<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > On 25 November 2016 at 11:32, Peet <<a href=3D"mailto:peet=
....@gmail.com">peet...@gmail.com</a>> wrote:<br>
>> ><br>
>> > Hello,<br>
>> ><br>
>> ><br>
>> > I was basically trying to implement a hash function in C++ us=
ing constant expressions (constexpr).<br>
>> > Sometimes it is necessary to cast a scalar type (or arrays) t=
o cv unsigned/signed char* to simply get the bytes and do some calculation.=
<br>
>> > Although it seems that reinterpret_casts aren't allowed i=
n constexpr (5.20/2.14).<br>
>> > Quickly googling this issue got me to this proposal:=C2=A0&qu=
ot;A Proposal to Relax Constexpr Restrictions for some Reinterpret Casts&qu=
ot; by=C2=A0Antony Polukhin [1].<br>
>> > This proposal relaxes the rule for reinterpret_cast in conste=
xpr so that we can actually cast cv void* to cv unsigned/signed char*.<br>
>> > Although I couldn't find any discussions about this onlin=
e, also it seems that the proposal hasn't been sent to the openstd mail=
ing-list.<br>
>> > Does anyone know if this proposal is still "alive" =
and if this is being considered proposing?<br>
>> ><br>
>> ><br>
>> > Regards,<br>
>> > Nick<br>
>> ><br>
>> ><br>
>> > [1]=C2=A0<a href=3D"https://apolukhin.github.io/constexpr_alg=
orithms/reinterpret.html">https://apolukhin.github.io/constexpr_algorithms/=
reinterpret.html</a><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> ><br>
>> > You received this message because you are subscribed to the G=
oogle Groups "ISO C++ Standard - Future Proposals" group.<br>
>> ><br>
>> > To unsubscribe from this group and stop receiving emails from=
it, send an email to <a href=3D"mailto:std-proposal...@isocpp.org">std-pro=
posal...@isocpp.org</a>.<br>
>> ><br>
>> > To post to this group, send email to <a href=3D"mailto:std-pr=
....@isocpp.org">std-pr...@isocpp.org</a>.<br>
>> ><br>
>> > To view this discussion on the web visit <a href=3D"https://g=
roups.google.com/a/isocpp.org/d/msgid/std-proposals/afbaf79e-305d-4408-98ab=
-5b35cfb11f27%40isocpp.org">https://groups.google.com/a/isocpp.org/d/msgid/=
std-proposals/afbaf79e-305d-4408-98ab-5b35cfb11f27%40isocpp.org</a>.<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> ><br>
>> > You received this message because you are subscribed to the G=
oogle Groups "ISO C++ Standard - Future Proposals" group.<br>
>> ><br>
>> > To unsubscribe from this group and stop receiving emails from=
it, send an email to <a href=3D"mailto:std-proposal...@isocpp.org">std-pro=
posal...@isocpp.org</a>.<br>
>> ><br>
>> > To post to this group, send email to <a href=3D"mailto:std-pr=
....@isocpp.org">std-pr...@isocpp.org</a>.<br>
>> ><br>
>> > To view this discussion on the web visit <a href=3D"https://g=
roups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya_VWQUMYGGd9tYy_c=
JWiwvsyUF2joMuCMPsPy%3DT6e15XA%40mail.gmail.com">https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/CALnjya_VWQUMYGGd9tYy_cJWiwvsyUF2joMuCMP=
sPy%3DT6e15XA%40mail.gmail.com</a>.<br>
>><br>
>> --<br>
>> You received this message because you are subscribed to the Google=
Groups "ISO C++ Standard - Future Proposals" group.<br>
>> To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">=
std-proposals+unsubscribe@isocpp.org</a>.<br>
>><br>
>> To post to this group, send email to <a href=3D"mailto:std-proposa=
ls@isocpp.org">std-proposals@isocpp.org</a>.<br>
>> To view this discussion on the web visit <a href=3D"https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/14dc989b-7a2f-478b-b16e-b929=
7fb1782f%40isocpp.org">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/14dc989b-7a2f-478b-b16e-b9297fb1782f%40isocpp.org</a>.<br>
><br>
><br>
> -- <br>
> You received this message because you are subscribed to a topic in the=
Google Groups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this topic, visit <a href=3D"https://groups.google=
..com/a/isocpp.org/d/topic/std-proposals/6tkocdbwVGU/unsubscribe">https://gr=
oups.google.com/a/isocpp.org/d/topic/std-proposals/6tkocdbwVGU/unsubscribe<=
/a>.<br>
> To unsubscribe from this group and all its topics, send an email to <a=
href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsub=
scribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/CAJwqTS_OGEOUiUE6rSRrREV6Yx9%2B4=
Sj5gA8CDHeYgXnPwErW6Q%40mail.gmail.com">https://groups.google.com/a/isocpp.=
org/d/msgid/std-proposals/CAJwqTS_OGEOUiUE6rSRrREV6Yx9%2B4Sj5gA8CDHeYgXnPwE=
rW6Q%40mail.gmail.com</a>.<br></p>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaJRPtdnHPX0%3DL89Pip2GC90aXrEY=
tJdUYxaHw1vwNJ%3Dw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaJRPtd=
nHPX0%3DL89Pip2GC90aXrEYtJdUYxaHw1vwNJ%3Dw%40mail.gmail.com</a>.<br />
--94eb2c070d62c45ee705426471e3--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 28 Nov 2016 16:01:17 -0800
Raw View
--94eb2c1913b6ce393d0542654a04
Content-Type: text/plain; charset=UTF-8
On 28 November 2016 at 15:00, 'Edward Catmur' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
> On 28 Nov 2016 22:50, "Peet Nick" <peetnick2@gmail.com> 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<intptr_t>(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.
However, we *can* support bit_cast for some pairs of source and destination
types (we can't support types containing a pointer, reference,
pointer-to-member, or class object with virtual functions or virtual bases
because we don't know the bit pattern, we can't support source objects that
have padding bits in locations where the destination needs a value, and we
can't support unions within the destination because we wouldn't know the
active member).
My hope is that bit_cast will provide access to a supportable subset of
operations here at compile time and defer the rest to runtime.
> so the other compilers would have to do the same, if they don't have an
> appropriate intrinsic available already.
>
> Remember, it's fine for library functions to need compiler magic to
> implement; part of the job of the standard library is to provide
> standardized interfaces to such magic.
>
> 1. http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0476r0.html
>
> > On Mon, Nov 28, 2016 at 11:35 PM, Edward Catmur <ed@catmur.co.uk> wrote:
> >>
> >> On Monday, 28 November 2016 22:04:42 UTC, Peet Nick wrote:
> >> > I am not sure how that would help? The destination type must have the
> same size as the source type, how would that help me getting the "raw byte
> view" of an scalar/pod?
> >>
> >> You would bit_cast to an array (or std::array) of unsigned char of the
> same size as your pod.
> >>
> >> > On Fri, Nov 25, 2016 at 4:32 PM, Mathias Gaunard <mat...@gaunard.com>
> wrote:
> >> >
> >> > I think you would have better luck with the new function bit_cast
> which might end up being constexpr.
> >> >
> >> >
> >> >
> >> >
> >> > On 25 November 2016 at 11:32, Peet <peet...@gmail.com> wrote:
> >> >
> >> > Hello,
> >> >
> >> >
> >> > I was basically trying to implement a hash function in C++ using
> constant expressions (constexpr).
> >> > Sometimes it is necessary to cast a scalar type (or arrays) to cv
> unsigned/signed char* to simply get the bytes and do some calculation.
> >> > Although it seems that reinterpret_casts aren't allowed in constexpr
> (5.20/2.14).
> >> > Quickly googling this issue got me to this proposal: "A Proposal to
> Relax Constexpr Restrictions for some Reinterpret Casts" by Antony Polukhin
> [1].
> >> > This proposal relaxes the rule for reinterpret_cast in constexpr so
> that we can actually cast cv void* to cv unsigned/signed char*.
> >> > Although I couldn't find any discussions about this online, also it
> seems that the proposal hasn't been sent to the openstd mailing-list.
> >> > Does anyone know if this proposal is still "alive" and if this is
> being considered proposing?
> >> >
> >> >
> >> > Regards,
> >> > Nick
> >> >
> >> >
> >> > [1] https://apolukhin.github.io/constexpr_algorithms/reinterpret.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-proposal...@isocpp.org.
> >> >
> >> > To post to this group, send email to std-pr...@isocpp.org.
> >> >
> >> > To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/afbaf79e-305d-4408-
> 98ab-5b35cfb11f27%40isocpp.org.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> >
> >> > 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-proposal...@isocpp.org.
> >> >
> >> > To post to this group, send email to std-pr...@isocpp.org.
> >> >
> >> > To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CALnjya_VWQUMYGGd9tYy_
> cJWiwvsyUF2joMuCMPsPy%3DT6e15XA%40mail.gmail.com.
> >>
> >> --
> >> 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/14dc989b-7a2f-478b-
> b16e-b9297fb1782f%40isocpp.org.
> >
> >
> > --
> > You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/6tkocdbwVGU/unsubscribe.
> > To unsubscribe from this group and all its topics, 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/CAJwqTS_OGEOUiUE6rSRrREV6Yx9%
> 2B4Sj5gA8CDHeYgXnPwErW6Q%40mail.gmail.com.
>
> --
> 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/CAJnLdOaJRPtdnHPX0%
> 3DL89Pip2GC90aXrEYtJdUYxaHw1vwNJ%3Dw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaJRPtdnHPX0%3DL89Pip2GC90aXrEYtJdUYxaHw1vwNJ%3Dw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAOfiQqk4ce1%3D%3DkUKZYH3ZLUVKMAG94vpQoYu9Bhh3Mc_zC7%3Deg%40mail.gmail.com.
--94eb2c1913b6ce393d0542654a04
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
8 November 2016 at 15:00, 'Edward Catmur' via ISO C++ Standard - Fu=
ture Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><span class=3D""><p dir=3D"ltr"></p>
<p dir=3D"ltr">On 28 Nov 2016 22:50, "Peet Nick" <<a href=3D"m=
ailto:peetnick2@gmail.com" target=3D"_blank">peetnick2@gmail.com</a>> wr=
ote:<br>
><br>
> 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?</p>
</span><p dir=3D"ltr">They'd have to use a compiler intrinsic; accordin=
g to [1] llvm already has a suitable opcode,</p></blockquote><div>That does=
n't help at all. Constant expression evaluation happens at a completely=
different layer from LLVM.</div><div><br></div><div>memcpy is fundamentall=
y not possible to support in general within constant expression evaluation;=
consider:<br></div><div><br></div><div>=C2=A0 int n;</div><div>=C2=A0 cons=
texpr int *p =3D &n; // ok</div><div>=C2=A0 constexpr intptr_t q =3D bi=
t_cast<intptr_t>(p); // ok?</div><div>=C2=A0 static_assert(q > 0x1=
234567); // ok?!</div><div><br></div><div>Clearly this example must be ill-=
formed. But either that means you can't do the bit_cast in a constant e=
xpression or that you can evaluate an integer as part of a constant express=
ion that you then can't do basic integer operations on.</div><div><br><=
/div><div>However, we *can* support bit_cast for some pairs of source and d=
estination types (we can't support types containing a pointer, referenc=
e, pointer-to-member, or class object with virtual functions or virtual bas=
es because we don't know the bit pattern, we can't support source o=
bjects that have padding bits in locations where the destination needs a va=
lue, and we can't support unions within the destination because we woul=
dn't know the active member).</div><div><br></div><div>My hope is that =
bit_cast will provide access to a supportable subset of operations here at =
compile time and defer the rest to runtime.</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><p dir=3D"ltr">so the other compilers would have to do the same, if th=
ey don't have an appropriate intrinsic available already. </p>
<p dir=3D"ltr">Remember, it's fine for library functions to need compil=
er magic to implement; part of the job of the standard library is to provid=
e standardized interfaces to such magic. </p>
<p dir=3D"ltr">1. <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers=
/2016/p0476r0.html" target=3D"_blank">http://open-std.org/JTC1/SC22/<wbr>WG=
21/docs/papers/2016/p0476r0.<wbr>html</a></p>
<p dir=3D"ltr"></p><div><div class=3D"h5">> On Mon, Nov 28, 2016 at 11:3=
5 PM, Edward Catmur <<a href=3D"mailto:ed@catmur.co.uk" target=3D"_blank=
">ed@catmur.co.uk</a>> wrote:<br>
>><br>
>> On Monday, 28 November 2016 22:04:42 UTC, Peet Nick=C2=A0 wrote:<b=
r>
>> > I am not sure how that would help? The destination type must =
have the same size as the source type, how would that help me getting the &=
quot;raw byte view" of an scalar/pod?<br>
>><br>
>> You would bit_cast to an array (or std::array) of unsigned char of=
the same size as your pod.<br>
>><br>
>> > On Fri, Nov 25, 2016 at 4:32 PM, Mathias Gaunard <<a href=
=3D"mailto:mat...@gaunard.com" target=3D"_blank">mat...@gaunard.com</a>>=
wrote:<br>
>> ><br>
>> > I think you would have better luck with the new function bit_=
cast which might end up being constexpr.<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > On 25 November 2016 at 11:32, Peet <<a href=3D"mailto:peet=
....@gmail.com" target=3D"_blank">peet...@gmail.com</a>> wrote:<br>
>> ><br>
>> > Hello,<br>
>> ><br>
>> ><br>
>> > I was basically trying to implement a hash function in C++ us=
ing constant expressions (constexpr).<br>
>> > Sometimes it is necessary to cast a scalar type (or arrays) t=
o cv unsigned/signed char* to simply get the bytes and do some calculation.=
<br>
>> > Although it seems that reinterpret_casts aren't allowed i=
n constexpr (5.20/2.14).<br>
>> > Quickly googling this issue got me to this proposal:=C2=A0&qu=
ot;A Proposal to Relax Constexpr Restrictions for some Reinterpret Casts&qu=
ot; by=C2=A0Antony Polukhin [1].<br>
>> > This proposal relaxes the rule for reinterpret_cast in conste=
xpr so that we can actually cast cv void* to cv unsigned/signed char*.<br>
>> > Although I couldn't find any discussions about this onlin=
e, also it seems that the proposal hasn't been sent to the openstd mail=
ing-list.<br>
>> > Does anyone know if this proposal is still "alive" =
and if this is being considered proposing?<br>
>> ><br>
>> ><br>
>> > Regards,<br>
>> > Nick<br>
>> ><br>
>> ><br>
>> > [1]=C2=A0<a href=3D"https://apolukhin.github.io/constexpr_alg=
orithms/reinterpret.html" target=3D"_blank">https://apolukhin.github.<wbr>i=
o/constexpr_algorithms/<wbr>reinterpret.html</a><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> ><br>
>> > You received this message because you are subscribed to the G=
oogle Groups "ISO C++ Standard - Future Proposals" group.<br>
>> ><br>
>> > To unsubscribe from this group and stop receiving emails from=
it, send an email to <a href=3D"mailto:std-proposal...@isocpp.org" target=
=3D"_blank">std-proposal...@isocpp.org</a>.<br>
>> ><br>
>> > To post to this group, send email to <a href=3D"mailto:std-pr=
....@isocpp.org" target=3D"_blank">std-pr...@isocpp.org</a>.<br>
>> ><br>
>> > To view this discussion on the web visit <a href=3D"https://g=
roups.google.com/a/isocpp.org/d/msgid/std-proposals/afbaf79e-305d-4408-98ab=
-5b35cfb11f27%40isocpp.org" target=3D"_blank">https://groups.google.com/a/<=
wbr>isocpp.org/d/msgid/std-<wbr>proposals/afbaf79e-305d-4408-<wbr>98ab-5b35=
cfb11f27%40isocpp.org</a><wbr>.<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> ><br>
>> > You received this message because you are subscribed to the G=
oogle Groups "ISO C++ Standard - Future Proposals" group.<br>
>> ><br>
>> > To unsubscribe from this group and stop receiving emails from=
it, send an email to <a href=3D"mailto:std-proposal...@isocpp.org" target=
=3D"_blank">std-proposal...@isocpp.org</a>.<br>
>> ><br>
>> > To post to this group, send email to <a href=3D"mailto:std-pr=
....@isocpp.org" target=3D"_blank">std-pr...@isocpp.org</a>.<br>
>> ><br>
>> > To view this discussion on the web visit <a href=3D"https://g=
roups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya_VWQUMYGGd9tYy_c=
JWiwvsyUF2joMuCMPsPy%3DT6e15XA%40mail.gmail.com" target=3D"_blank">https://=
groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CALnjya_<wbr=
>VWQUMYGGd9tYy_<wbr>cJWiwvsyUF2joMuCMPsPy%<wbr>3DT6e15XA%40mail.gmail.com</=
a>.<br>
>><br>
>> --<br>
>> You received this message because you are subscribed to the Google=
Groups "ISO C++ Standard - Future Proposals" group.<br>
>> To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" =
target=3D"_blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
>><br>
>> To post to this group, send email to <a href=3D"mailto:std-proposa=
ls@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
>> To view this discussion on the web visit <a href=3D"https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/14dc989b-7a2f-478b-b16e-b929=
7fb1782f%40isocpp.org" target=3D"_blank">https://groups.google.com/a/<wbr>i=
socpp.org/d/msgid/std-<wbr>proposals/14dc989b-7a2f-478b-<wbr>b16e-b9297fb17=
82f%40isocpp.org</a><wbr>.<br>
><br>
><br>
> -- <br></div></div>
> You received this message because you are subscribed to a topic in the=
Google Groups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this topic, visit <a href=3D"https://groups.google=
..com/a/isocpp.org/d/topic/std-proposals/6tkocdbwVGU/unsubscribe" target=3D"=
_blank">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>propos=
als/6tkocdbwVGU/<wbr>unsubscribe</a>.<br>
> To unsubscribe from this group and all its topics, send an email to <a=
href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">s=
td-proposals+unsubscribe@<wbr>isocpp.org</a>.<span class=3D""><br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
> To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/CAJwqTS_OGEOUiUE6rSRrREV6Yx9%2B4=
Sj5gA8CDHeYgXnPwErW6Q%40mail.gmail.com" target=3D"_blank">https://groups.go=
ogle.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CAJwqTS_<wbr>OGEOUiUE=
6rSRrREV6Yx9%<wbr>2B4Sj5gA8CDHeYgXnPwErW6Q%<wbr>40mail.gmail.com</a>.<br></=
span><p></p><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaJRPtdnHPX0%3DL89Pip2GC90aXrEY=
tJdUYxaHw1vwNJ%3Dw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CAJnLdOaJRPtdnHPX0%<wbr>3DL89Pip2GC90aXrEYtJdUYxaHw1vw<w=
br>NJ%3Dw%40mail.gmail.com</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqk4ce1%3D%3DkUKZYH3ZLUVKMAG94vp=
QoYu9Bhh3Mc_zC7%3Deg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqk4ce=
1%3D%3DkUKZYH3ZLUVKMAG94vpQoYu9Bhh3Mc_zC7%3Deg%40mail.gmail.com</a>.<br />
--94eb2c1913b6ce393d0542654a04--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 28 Nov 2016 18:07:57 -0800 (PST)
Raw View
------=_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 <std-pr...@isocpp.org <javascript:>> wrote:
>
>> On 28 Nov 2016 22:50, "Peet Nick" <peet...@gmail.com <javascript:>>
>> 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<intptr_t>(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
<div dir=3D"ltr"><br><br>On Monday, November 28, 2016 at 7:01:39 PM UTC-5, =
Richard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On 28 November 2016 at 15:00, '=
;Edward Catmur' via ISO C++ Standard - Future Proposals <span dir=3D"lt=
r"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"I=
ZKh3UQBBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&#=
39;;return true;" onclick=3D"this.href=3D'javascript:';return true;=
">std-pr...@isocpp.org</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><span><p dir=3D"ltr"></p>
<p dir=3D"ltr">On 28 Nov 2016 22:50, "Peet Nick" <<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"IZKh3UQBBQAJ" rel=3D=
"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;">peet...@gmail.com=
</a>> wrote:<br>
><br>
> 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?</p>
</span><p dir=3D"ltr">They'd have to use a compiler intrinsic; accordin=
g to [1] llvm already has a suitable opcode,</p></blockquote><div>That does=
n't help at all. Constant expression evaluation happens at a completely=
different layer from LLVM.</div><div><br></div><div>memcpy is fundamentall=
y not possible to support in general within constant expression evaluation;=
consider:<br></div><div><br></div><div>=C2=A0 int n;</div><div>=C2=A0 cons=
texpr int *p =3D &n; // ok</div><div>=C2=A0 constexpr intptr_t q =3D bi=
t_cast<intptr_t>(p); // ok?</div><div>=C2=A0 static_assert(q > 0x1=
234567); // ok?!</div><div><br></div></div></div></div></blockquote><div></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div=
class=3D"gmail_quote"><div></div><div>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></div></div><=
/div></blockquote><div><br>This is <i>precisely</i> 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};`.<br><br>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.<br><br>So there's no problem.<br></di=
v></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/591447c7-38cd-4ad4-83aa-fc1326c1829e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/591447c7-38cd-4ad4-83aa-fc1326c1829e=
%40isocpp.org</a>.<br />
------=_Part_13346_2096209644.1480385277640--
------=_Part_13345_1176416860.1480385277639--
.
Author: Myriachan <myriachan@gmail.com>
Date: Fri, 2 Dec 2016 17:32:34 -0800 (PST)
Raw View
------=_Part_2085_10541132.1480728754340
Content-Type: multipart/alternative;
boundary="----=_Part_2086_1171094534.1480728754340"
------=_Part_2086_1171094534.1480728754340
Content-Type: text/plain; charset=UTF-8
On Monday, November 28, 2016 at 6:07:57 PM UTC-8, Nicol Bolas wrote:
>
> 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.
>
As far as I can tell, constexpr bit_cast would be useful for implementing
things that'd otherwise require direct compiler support, such as
std::numeric_limits<float>::infinity(). Am I right in this assumption?
Melissa
--
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/569dee8e-b869-40e0-9b41-1d1f39fecb12%40isocpp.org.
------=_Part_2086_1171094534.1480728754340
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, November 28, 2016 at 6:07:57 PM UTC-8, Nicol Bo=
las wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Thi=
s is <i>precisely</i> why `bit_cast` is a good thing. Because it's a fu=
nction which knows both the source and destination 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};`.<br><div><br>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.<br><br>So there's no problem.<br></di=
v></div></blockquote><div><br>As far as I can tell, constexpr bit_cast woul=
d be useful for implementing things that'd otherwise require direct com=
piler support, such as std::numeric_limits<float>::infinity().=C2=A0 =
Am I right in this assumption?<br><br>Melissa<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/569dee8e-b869-40e0-9b41-1d1f39fecb12%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/569dee8e-b869-40e0-9b41-1d1f39fecb12=
%40isocpp.org</a>.<br />
------=_Part_2086_1171094534.1480728754340--
------=_Part_2085_10541132.1480728754340--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 02 Dec 2016 18:39:23 -0800
Raw View
On sexta-feira, 2 de dezembro de 2016 17:32:34 PST Myriachan wrote:
> As far as I can tell, constexpr bit_cast would be useful for implementing
> things that'd otherwise require direct compiler support, such as
> std::numeric_limits<float>::infinity(). Am I right in this assumption?
Probably, but not for infinity(). That can be implemented by doing max() *
max().
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/5751472.mzv4v8F4CI%40tjmaciei-mobl1.
.