Topic: A proposal for C++: bit_cast.
Author: "'Nicholas Chapman' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 6 Oct 2015 12:57:36 -0700 (PDT)
Raw View
------=_Part_973_1735900805.1444161456317
Content-Type: multipart/alternative;
boundary="----=_Part_974_2024019638.1444161456317"
------=_Part_974_2024019638.1444161456317
Content-Type: text/plain; charset=UTF-8
Hi all,
I'd like to propose a bit_cast function.
bit_cast<T>(x) would get the bits of x, and reinterpret them as the bits of
a value of type T.
For example, you would be able to write
float x = 1.0f;
const uint32_t y = bit_cast<uint32_t>(x);
And then y would have the value 0x3f800000.
I have written some details about it on my blog here:
http://www.forwardscattering.org/post/27
I won't copy and paste the text here unless anyone requests it.
There was a discussion on reddit about it
here: https://www.reddit.com/r/programming/comments/3nmoo7/a_proposal_for_c_bit_cast/
Thanks,
Nick C.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_974_2024019638.1444161456317
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi all,</div><div>I'd like to propose a bit_cast =
function.</div><div><br></div><div><div>bit_cast<T>(x) would get the =
bits of x, and reinterpret them as the bits of a value of type T.</div><div=
><br></div><div>For example, you would be able to write</div><div><br></div=
><div>float x =3D 1.0f;</div><div>const uint32_t y =3D bit_cast<uint32_t=
>(x);</div><div><br></div><div>And then y would have the value 0x3f80000=
0.</div></div><div><br></div><div>I have written some details about it on m=
y blog here:</div><div><br></div>http://www.forwardscattering.org/post/27<b=
r><div><br></div><div>I won't copy and paste the text here unless anyon=
e requests it.</div><div>There was a discussion on reddit about it here:=C2=
=A0https://www.reddit.com/r/programming/comments/3nmoo7/a_proposal_for_c_bi=
t_cast/</div><div><br></div><div>Thanks,</div><div>=C2=A0 Nick C.</div></di=
v>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_974_2024019638.1444161456317--
------=_Part_973_1735900805.1444161456317--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 06 Oct 2015 22:53:14 +0200
Raw View
On Tuesday 06 October 2015 12:57:36 'Nicholas Chapman' via ISO C++ Standard -
Future Proposals wrote:
> Hi all,
> I'd like to propose a bit_cast function.
>
> bit_cast<T>(x) would get the bits of x, and reinterpret them as the bits of
> a value of type T.
Makes sense, it's a simple yet powerful library addition. As you've explained
in your blog, this happens quite often, especially when dealing with the
example you have: dealing with floating points. I had to write code to deal
with that last week, as using the math.h/cmath functions generated (much)
worse code than what was needed, and my solution was memcpy (GCC is smart
enough to optimise memcpy+bswap to one assembly instruction).
The most common implementation will be the memcpy case, though compilers may
implement an intrinsic to do the actual operation if they wish.
> For example, you would be able to write
>
> float x = 1.0f;
> const uint32_t y = bit_cast<uint32_t>(x);
>
> And then y would have the value 0x3f800000.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Tue, 6 Oct 2015 23:28:46 -0700 (PDT)
Raw View
------=_Part_535_442570732.1444199326448
Content-Type: multipart/alternative;
boundary="----=_Part_536_830640605.1444199326449"
------=_Part_536_830640605.1444199326449
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, October 6, 2015 at 12:57:36 PM UTC-7, Nicholas Chapman wrote:
>
> Hi all,
> I'd like to propose a bit_cast function.
>
> bit_cast<T>(x) would get the bits of x, and reinterpret them as the bits=
=20
> of a value of type T.
>
> For example, you would be able to write
>
> float x =3D 1.0f;
> const uint32_t y =3D bit_cast<uint32_t>(x);
>
> And then y would have the value 0x3f800000.
>
Do you want exactly this?
template<class T, class U>
T bit_cast(U u)
{
static_assert(sizeof(T) =3D=3D sizeof(U));
T result;
memcpy(&result, &u, sizeof u);
return result;
}
If so, I think the C++ language doesn't provide it because it's easy to=20
write on your own.
The reddit discussion points out that one disadvantage of the "easy to=20
write" version is that it's not constexpr.
But is that an argument in favor of bit_cast<>, or an argument in favor of=
=20
constexpr memcpy? (It's not a crazy idea. We already have constexpr=20
for-loops and constexpr assignments; the problem is that we currently lack=
=20
a constexpr way to talk about pointers and addresses.)
=E2=80=93Arthur
--=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_536_830640605.1444199326449
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, October 6, 2015 at 12:57:36 PM UTC-7, Nicholas=
Chapman 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=
"><div>Hi all,</div><div>I'd like to propose a bit_cast function.</div>=
<div><br></div><div><div>bit_cast<T>(x) would get the bits of x, and =
reinterpret them as the bits of a value of type T.</div></div></div></block=
quote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv><br></div><div>For example, you would be able to write</div><div><br></d=
iv><div>float x =3D 1.0f;</div><div>const uint32_t y =3D bit_cast<uint32=
_t>(x);</div><div><br></div><div>And then y would have the value 0x3f800=
000.</div></div></div></blockquote><div><br></div><div>Do you want exactly =
this?</div><div><br></div><div>template<class T, class U></div><div>T=
bit_cast(U u)</div><div>{</div><div>=C2=A0 =C2=A0 static_assert(sizeof(T) =
=3D=3D sizeof(U));</div><div>=C2=A0 =C2=A0 T result;</div><div>=C2=A0 =C2=
=A0 memcpy(&result, &u, sizeof u);</div><div>=C2=A0 =C2=A0 return r=
esult;</div><div>}</div><div><br></div><div>If so, I think the C++ language=
doesn't provide it because it's easy to write on your own.</div><d=
iv><br></div><div>The reddit discussion points out that one disadvantage of=
the "easy to write" version is that it's not constexpr.</div=
><div>But is that an argument in favor of bit_cast<>, or an argument =
in favor of constexpr memcpy? =C2=A0(It's not a crazy idea. We already =
have constexpr for-loops and constexpr assignments; the problem is that we =
currently lack a constexpr way to talk about pointers and addresses.)</div>=
<div><br></div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_536_830640605.1444199326449--
------=_Part_535_442570732.1444199326448--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 7 Oct 2015 16:01:46 +0800
Raw View
--Apple-Mail=_A16614FB-BFD3-4947-9E46-B3A7B99ED6AB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9310=E2=80=9307, at 2:28 PM, Arthur O'Dwyer <arthur.j.odwye=
r@gmail.com> wrote:
>=20
> The reddit discussion points out that one disadvantage of the "easy to wr=
ite" version is that it's not constexpr.
> But is that an argument in favor of bit_cast<>, or an argument in favor o=
f constexpr memcpy? (It's not a crazy idea. We already have constexpr for-=
loops and constexpr assignments; the problem is that we currently lack a co=
nstexpr way to talk about pointers and addresses.)
We already have constexpr trivially-copyable unions and constexpr pointer a=
rithmetic (within an array). What constexpr lacks is a way to access object=
representations, or any implementation-specific aspects of execution at al=
l. It executes the portable parts of the language but otherwise it=E2=80=99=
s not a target machine emulator.
If constexpr gains anything in this direction, it should be the primitive s=
tatic_cast<obj*>(void_ptr) operation. From there, you can get reinterpret_c=
ast<char*>, memcpy, and whatever is deemed appropriate.
--=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=_A16614FB-BFD3-4947-9E46-B3A7B99ED6AB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9307, at 2:28 PM, Arthur O'Dwyer <<a href=3D"mailto:arthur.j.odwy=
er@gmail.com" class=3D"">arthur.j.odwyer@gmail.com</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=
=3D""><div class=3D"">The reddit discussion points out that one disadvantag=
e of the "easy to write" version is that it's not constexpr.</div><div clas=
s=3D"">But is that an argument in favor of bit_cast<>, or an argument=
in favor of constexpr memcpy? (It's not a crazy idea. We already hav=
e constexpr for-loops and constexpr assignments; the problem is that we cur=
rently lack a constexpr way to talk about pointers and addresses.)</div></d=
iv></div></blockquote><br class=3D""></div><div>We already have constexpr t=
rivially-copyable unions and constexpr pointer arithmetic (within an array)=
.. What constexpr lacks is a way to access object representations, or any im=
plementation-specific aspects of execution at all. It executes the portable=
parts of the language but otherwise it=E2=80=99s not a target machine emul=
ator.</div><br class=3D""><div class=3D"">If constexpr gains anything in th=
is direction, it should be the primitive <font face=3D"Courier" class=3D"">=
static_cast<obj*>(void_ptr)</font> operation. From there, you can get=
<font face=3D"Courier" class=3D"">reinterpret_cast<char*></font>, <f=
ont face=3D"Courier" class=3D"">memcpy</font>, and whatever is deemed appro=
priate.</div><div class=3D""><br class=3D""></div></body></html>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_A16614FB-BFD3-4947-9E46-B3A7B99ED6AB--
.
Author: "'Nicholas Chapman' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 7 Oct 2015 14:07:56 -0700 (PDT)
Raw View
------=_Part_303_771801200.1444252076829
Content-Type: multipart/alternative;
boundary="----=_Part_304_2025354989.1444252076829"
------=_Part_304_2025354989.1444252076829
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, October 7, 2015 at 7:28:46 AM UTC+1, Arthur O'Dwyer wrote:
> On Tuesday, October 6, 2015 at 12:57:36 PM UTC-7, Nicholas Chapman wrote:
>>
>> Hi all,
>> I'd like to propose a bit_cast function.
>>
>> bit_cast<T>(x) would get the bits of x, and reinterpret them as the bits=
=20
>> of a value of type T.
>>
>
>> For example, you would be able to write
>>
>> float x =3D 1.0f;
>> const uint32_t y =3D bit_cast<uint32_t>(x);
>>
>> And then y would have the value 0x3f800000.
>>
>
> Do you want exactly this?=20
>
> template<class T, class U>
> T bit_cast(U u)
> {
> static_assert(sizeof(T) =3D=3D sizeof(U));
> T result;
> memcpy(&result, &u, sizeof u);
> return result;
> }
>
> If so, I think the C++ language doesn't provide it because it's easy to=
=20
> write on your own.
>
Yes, basically I want exactly that.
=20
>
> The reddit discussion points out that one disadvantage of the "easy to=20
> write" version is that it's not constexpr.
> But is that an argument in favor of bit_cast<>, or an argument in favor o=
f=20
> constexpr memcpy? (It's not a crazy idea. We already have constexpr=20
> for-loops and constexpr assignments; the problem is that we currently lac=
k=20
> a constexpr way to talk about pointers and addresses.)
>
> =E2=80=93Arthur
>
--=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_304_2025354989.1444252076829
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>On Wednesday, October 7, 2015 at 7:28:46 AM UTC+1, Ar=
thur O'Dwyer wrote:<br></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">On Tuesday, October 6, 2015 at 12:57:36 PM UTC-7, Nicho=
las Chapman wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div>Hi all,</div><div>I'd like to propose a bit_cast function.</div><d=
iv><br></div><div><div>bit_cast<T>(x) would get the bits of x, and re=
interpret them as the bits of a value of type T.</div></div></div></blockqu=
ote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><br>=
</div><div>For example, you would be able to write</div><div><br></div><div=
>float x =3D 1.0f;</div><div>const uint32_t y =3D bit_cast<uint32_t>(=
x);</div><div><br></div><div>And then y would have the value 0x3f800000.</d=
iv></div></div></blockquote><div><br></div><div>Do you want exactly this?=
=C2=A0</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div><br></div><div>template<class T, class U></div=
><div>T bit_cast(U u)</div><div>{</div><div>=C2=A0 =C2=A0 static_assert(siz=
eof(T) =3D=3D sizeof(U));</div><div>=C2=A0 =C2=A0 T result;</div><div>=C2=
=A0 =C2=A0 memcpy(&result, &u, sizeof u);</div><div>=C2=A0 =C2=A0 r=
eturn result;</div><div>}</div><div><br></div><div>If so, I think the C++ l=
anguage doesn't provide it because it's easy to write on your own.<=
/div></div></blockquote><div><br></div><div>Yes, basically I want exactly t=
hat.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><br></div><div>The reddit discussion points out that one=
disadvantage of the "easy to write" version is that it's not=
constexpr.</div><div>But is that an argument in favor of bit_cast<>,=
or an argument in favor of constexpr memcpy? =C2=A0(It's not a crazy i=
dea. We already have constexpr for-loops and constexpr assignments; the pro=
blem is that we currently lack a constexpr way to talk about pointers and a=
ddresses.)</div><div><br></div><div>=E2=80=93Arthur</div></div></blockquote=
></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_304_2025354989.1444252076829--
------=_Part_303_771801200.1444252076829--
.
Author: Christopher Horvath <blackencino@gmail.com>
Date: Wed, 7 Oct 2015 14:21:44 -0700
Raw View
--001a113f8e26573cbb05218a558a
Content-Type: text/plain; charset=UTF-8
>
>
>
>> template<class T, class U>
>> T bit_cast(U u)
>> {
>> static_assert(sizeof(T) == sizeof(U));
>> T result;
>> memcpy(&result, &u, sizeof u);
>> return result;
>> }
>>
>> If so, I think the C++ language doesn't provide it because it's easy to
>> write on your own.
>>
>
> Yes, basically I want exactly that.
>
>
>>
>>
I think there's a big difference between "easy to write on your own" and
"easy to know that this is the right way to do the thing". I think having
bit_cast would be tremendously valuable as a certification of this being
the right thing to do, or the right way to do it.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113f8e26573cbb05218a558a
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><br><blockquot=
e 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><br></div><div>template=
<class T, class U></div><div>T bit_cast(U u)</div><div>{</div><div>=
=C2=A0 =C2=A0 static_assert(sizeof(T) =3D=3D sizeof(U));</div><div>=C2=A0 =
=C2=A0 T result;</div><div>=C2=A0 =C2=A0 memcpy(&result, &u, sizeof=
u);</div><div>=C2=A0 =C2=A0 return result;</div><div>}</div><div><br></div=
><div>If so, I think the C++ language doesn't provide it because it'=
;s easy to write on your own.</div></div></blockquote><div><br></div></span=
><div>Yes, basically I want exactly that.</div><span class=3D""><div>=C2=A0=
</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><br></d=
iv></div></blockquote></span></div></blockquote><div><br></div><div>I think=
there's a big difference between "easy to write on your own"=
and "easy to know that this is the right way to do the thing".=
=C2=A0 I think having bit_cast would be tremendously valuable as a certific=
ation of this being the right thing to do, or the right way to do it.</div>=
<div>=C2=A0<br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113f8e26573cbb05218a558a--
.
Author: "'Nicholas Chapman' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 7 Oct 2015 14:39:16 -0700 (PDT)
Raw View
------=_Part_392_2057810921.1444253956584
Content-Type: multipart/alternative;
boundary="----=_Part_393_1878358912.1444253956584"
------=_Part_393_1878358912.1444253956584
Content-Type: text/plain; charset=UTF-8
>>
>>> template<class T, class U>
>>> T bit_cast(U u)
>>> {
>>> static_assert(sizeof(T) == sizeof(U));
>>> T result;
>>> memcpy(&result, &u, sizeof u);
>>> return result;
>>> }
>>>
>>> If so, I think the C++ language doesn't provide it because it's easy to
>>> write on your own.
>>>
>>
>> Yes, basically I want exactly that.
>>
>>
>>>
>>>
> I think there's a big difference between "easy to write on your own" and
> "easy to know that this is the right way to do the thing". I think having
> bit_cast would be tremendously valuable as a certification of this being
> the right thing to do, or the right way to do it.
>
>
> Yes, exactly. I would like the language to codify the proper and correct
way to bit cast. I want to know that the code I write will be efficient,
and that it won't be declared undefined 5 years from now.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_393_1878358912.1444253956584
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br><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"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<span><br><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><br=
></div><div>template<class T, class U></div><div>T bit_cast(U u)</div=
><div>{</div><div>=C2=A0 =C2=A0 static_assert(sizeof(T) =3D=3D sizeof(U));<=
/div><div>=C2=A0 =C2=A0 T result;</div><div>=C2=A0 =C2=A0 memcpy(&resul=
t, &u, sizeof u);</div><div>=C2=A0 =C2=A0 return result;</div><div>}</d=
iv><div><br></div><div>If so, I think the C++ language doesn't provide =
it because it's easy to write on your own.</div></div></blockquote><div=
><br></div></span><div>Yes, basically I want exactly that.</div><span><div>=
=C2=A0</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><=
br></div></div></blockquote></span></div></blockquote><div><br></div><div>I=
think there's a big difference between "easy to write on your own=
" and "easy to know that this is the right way to do the thing&qu=
ot;.=C2=A0 I think having bit_cast would be tremendously valuable as a cert=
ification of this being the right thing to do, or the right way to do it.</=
div><div>=C2=A0<br></div></div><br></div></div></blockquote><div>Yes, exact=
ly. =C2=A0I would like the language to codify the proper and correct way to=
bit cast. =C2=A0I want to know that the code I write will be efficient, an=
d that it won't be declared undefined 5 years from now.</div><div>=C2=
=A0</div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_393_1878358912.1444253956584--
------=_Part_392_2057810921.1444253956584--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 7 Oct 2015 14:48:45 -0700
Raw View
--001a11c2feb2f1a34905218ab523
Content-Type: text/plain; charset=UTF-8
On Wed, Oct 7, 2015 at 2:21 PM, Christopher Horvath <blackencino@gmail.com>
wrote:
>
> I think there's a big difference between "easy to write on your own" and
> "easy to know that this is the right way to do the thing". I think having
> bit_cast would be tremendously valuable as a certification of this being
> the right thing to do, or the right way to do it.
>
+1
Even for things that are otherwise trivial (or seemingly trivial), it's
useful to have such a function. std::max and std::min are pretty trivial,
for example, but the function is still useful... even though it's generally
acknowledged that we messed up in the standard specification. It's easy to
underestimate the value of simple functions.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c2feb2f1a34905218ab523
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 W=
ed, Oct 7, 2015 at 2:21 PM, Christopher Horvath <span dir=3D"ltr"><<a hr=
ef=3D"mailto:blackencino@gmail.com" target=3D"_blank">blackencino@gmail.com=
</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div>I think there's a=
big difference between "easy to write on your own" and "eas=
y to know that this is the right way to do the thing".=C2=A0 I think h=
aving bit_cast would be tremendously valuable as a certification of this be=
ing the right thing to do, or the right way to do it.</div></div></div></di=
v></blockquote><div><br></div><div>+1</div><div><br></div><div>Even for thi=
ngs that are otherwise trivial (or seemingly trivial), it's useful to h=
ave such a function. std::max and std::min are pretty trivial, for example,=
but the function is still useful... even though it's generally acknowl=
edged that we messed up in the standard specification. It's easy to und=
erestimate the value of simple functions.<br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2feb2f1a34905218ab523--
.
Author: "'Nicholas Chapman' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 7 Oct 2015 14:57:08 -0700 (PDT)
Raw View
------=_Part_725_845374971.1444255028440
Content-Type: multipart/alternative;
boundary="----=_Part_726_156643456.1444255028440"
------=_Part_726_156643456.1444255028440
Content-Type: text/plain; charset=UTF-8
As someone mentioned on the reddit thread, another possibility is to change
the definition of reinterpret_cast to support the kind of stuff bit_cast
would
do: https://www.reddit.com/r/programming/comments/3nmoo7/a_proposal_for_c_bit_cast/cvpocfe
I don't know enough about the original design and intention of the C++
casts to say if this is a good idea or not.
Does someone want to chime in on this?
Why doesn't reinterpret cast work like this in the first place?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_726_156643456.1444255028440
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">As someone mentioned on the reddit thread, another possibi=
lity is to change the definition of reinterpret_cast to support the kind of=
stuff bit_cast would do:=C2=A0https://www.reddit.com/r/programming/comment=
s/3nmoo7/a_proposal_for_c_bit_cast/cvpocfe<div>I don't know enough abou=
t the original design and intention of the C++ casts to say if this is a go=
od idea or not.</div><div>Does someone want to chime in on this?</div><div>=
Why doesn't reinterpret cast work like this in the first place?</div><d=
iv><br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_726_156643456.1444255028440--
------=_Part_725_845374971.1444255028440--
.
Author: Christopher Horvath <blackencino@gmail.com>
Date: Wed, 7 Oct 2015 15:03:19 -0700
Raw View
--047d7bf17eea15d18d05218aead7
Content-Type: text/plain; charset=UTF-8
On Wed, Oct 7, 2015 at 2:57 PM, 'Nicholas Chapman' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> As someone mentioned on the reddit thread, another possibility is to
> change the definition of reinterpret_cast to support the kind of stuff
> bit_cast would do:
> https://www.reddit.com/r/programming/comments/3nmoo7/a_proposal_for_c_bit_cast/cvpocfe
> I don't know enough about the original design and intention of the C++
> casts to say if this is a good idea or not.
> Does someone want to chime in on this?
> Why doesn't reinterpret cast work like this in the first place?
>
> I'm embarrassed to say that prior to this discussion, that's _exactly_
what I thought reinterpret_cast already did!
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bf17eea15d18d05218aead7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Oct 7, 2015 at 2:57 PM, 'Nicholas Chapman' via ISO C++ =
Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-pro=
posals@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;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">As someone ment=
ioned on the reddit thread, another possibility is to change the definition=
of reinterpret_cast to support the kind of stuff bit_cast would do:=C2=A0<=
a href=3D"https://www.reddit.com/r/programming/comments/3nmoo7/a_proposal_f=
or_c_bit_cast/cvpocfe" target=3D"_blank">https://www.reddit.com/r/programmi=
ng/comments/3nmoo7/a_proposal_for_c_bit_cast/cvpocfe</a><div>I don't kn=
ow enough about the original design and intention of the C++ casts to say i=
f this is a good idea or not.</div><div>Does someone want to chime in on th=
is?</div><div>Why doesn't reinterpret cast work like this in the first =
place?</div><div><br></div></div></blockquote><div>I'm embarrassed to s=
ay that prior to this discussion, that's _exactly_ what I thought reint=
erpret_cast already did!=C2=A0</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div></div></div><div class=3D"HOEnZb"><div class=
=3D"h5">
<p></p>
-- <br>
<br>
--- <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@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bf17eea15d18d05218aead7--
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Thu, 8 Oct 2015 11:05:04 +0330
Raw View
--001a1149a17826e0bb052192e91f
Content-Type: text/plain; charset=UTF-8
template <typename Target>
struct StrCaster{
typedef
constexpr StrCaster(Target const& src)
: mData(src) {};
template <typename Other>
constexpr StrCaster(StrCaster<Other> const& init)
{
static_assert (sizeof (Other)==sizeof(Target));
for(auto i=0;i<sizeof(Target);++i)
mBytes[i]=init.mBytes[i];
};
constexpr operator Target(){return mData;};
private:
union{
Target mData;
char mBytes[sizeof(Target )];
};
};
template <typename Out,typename In>
constexpr Out bit_cast(In const val)
{
StrCaster<In> in {val};
return StrCaster<Out>{in};
};
2015-10-08 1:33 GMT+03:30 Christopher Horvath <blackencino@gmail.com>:
>
>
> On Wed, Oct 7, 2015 at 2:57 PM, 'Nicholas Chapman' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> As someone mentioned on the reddit thread, another possibility is to
>> change the definition of reinterpret_cast to support the kind of stuff
>> bit_cast would do:
>> https://www.reddit.com/r/programming/comments/3nmoo7/a_proposal_for_c_bit_cast/cvpocfe
>> I don't know enough about the original design and intention of the C++
>> casts to say if this is a good idea or not.
>> Does someone want to chime in on this?
>> Why doesn't reinterpret cast work like this in the first place?
>>
>> I'm embarrassed to say that prior to this discussion, that's _exactly_
> what I thought reinterpret_cast already did!
>
>
>> --
>>
>> ---
>> 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.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> --
---
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.
Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.
--
how am I supposed to end the twisted road of your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1149a17826e0bb052192e91f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><div class=3D"gmail_default" style=3D"font-family:'ari=
al narrow',sans-serif;font-size:large" dir=3D"ltr">template <typenam=
e Target></div><div class=3D"gmail_default" style=3D"font-family:'ar=
ial narrow',sans-serif;font-size:large" dir=3D"ltr">struct StrCaster{</=
div><div class=3D"gmail_default" style=3D"font-family:'arial narrow'=
;,sans-serif;font-size:large" dir=3D"ltr">=C2=A0 =C2=A0 =C2=A0typedef=C2=A0=
</div><div class=3D"gmail_default" style=3D"font-family:'arial narrow&#=
39;,sans-serif;font-size:large" dir=3D"ltr">=C2=A0 =C2=A0 =C2=A0constexpr S=
trCaster(Target const& src)</div><div class=3D"gmail_default" style=3D"=
font-family:'arial narrow',sans-serif;font-size:large" dir=3D"ltr">=
=C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0mData(src) {};</div><div class=3D"gmail_=
default" style=3D"font-family:'arial narrow',sans-serif;font-size:l=
arge" dir=3D"ltr"><br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:'arial narrow',sans-serif;font-size:large" dir=3D"ltr">=C2=A0 =
=C2=A0 =C2=A0template <typename Other></div><div class=3D"gmail_defau=
lt" style=3D"font-family:'arial narrow',sans-serif;font-size:large"=
dir=3D"ltr">=C2=A0 =C2=A0 =C2=A0constexpr StrCaster(StrCaster<Other>=
const& init)</div><div class=3D"gmail_default" style=3D"font-family:&#=
39;arial narrow',sans-serif;font-size:large" dir=3D"ltr">=C2=A0 =C2=A0 =
=C2=A0{</div><div class=3D"gmail_default" style=3D"font-family:'arial n=
arrow',sans-serif;font-size:large" dir=3D"ltr">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 static_assert (sizeof (Other)=3D=3Dsizeof(Target));</div>=
<div class=3D"gmail_default" style=3D"font-family:'arial narrow',sa=
ns-serif;font-size:large" dir=3D"ltr">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 for(auto i=3D0;i<sizeof(Target);++i)</div><div class=3D"gmail_def=
ault" style=3D"font-family:'arial narrow',sans-serif;font-size:larg=
e" dir=3D"ltr">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mByt=
es[i]=3Dinit.mBytes[i];</div><div class=3D"gmail_default" style=3D"font-fam=
ily:'arial narrow',sans-serif;font-size:large" dir=3D"ltr">=C2=A0 =
=C2=A0 =C2=A0};</div><div class=3D"gmail_default" style=3D"font-family:'=
;arial narrow',sans-serif;font-size:large" dir=3D"ltr">constexpr operat=
or Target(){return mData;};</div><div class=3D"gmail_default" style=3D"font=
-family:'arial narrow',sans-serif;font-size:large" dir=3D"ltr">priv=
ate:</div><div class=3D"gmail_default" style=3D"font-family:'arial narr=
ow',sans-serif;font-size:large" dir=3D"ltr">=C2=A0 =C2=A0 =C2=A0union{<=
/div><div class=3D"gmail_default" style=3D"font-family:'arial narrow=
9;,sans-serif;font-size:large" dir=3D"ltr">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0Target mData;</div><div class=3D"gmail_default" style=3D"font-fam=
ily:'arial narrow',sans-serif;font-size:large" dir=3D"ltr">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 char mBytes[sizeof(Target )];</div><div =
class=3D"gmail_default" style=3D"font-family:'arial narrow',sans-se=
rif;font-size:large" dir=3D"ltr">=C2=A0 =C2=A0 =C2=A0};</div><div class=3D"=
gmail_default" style=3D"font-family:'arial narrow',sans-serif;font-=
size:large" dir=3D"ltr">};</div><div class=3D"gmail_default" style=3D"font-=
family:'arial narrow',sans-serif;font-size:large" dir=3D"ltr"><br><=
/div><div class=3D"gmail_default" style=3D"font-family:'arial narrow=
9;,sans-serif;font-size:large" dir=3D"ltr">template <typename Out,typena=
me In></div><div class=3D"gmail_default" style=3D"font-family:'arial=
narrow',sans-serif;font-size:large" dir=3D"ltr">constexpr Out bit_cast=
(In const val)</div><div class=3D"gmail_default" style=3D"font-family:'=
arial narrow',sans-serif;font-size:large" dir=3D"ltr">{</div><div class=
=3D"gmail_default" style=3D"font-family:'arial narrow',sans-serif;f=
ont-size:large" dir=3D"ltr">=C2=A0 =C2=A0 =C2=A0 =C2=A0StrCaster<In> =
in {val};</div><div class=3D"gmail_default" style=3D"font-family:'arial=
narrow',sans-serif;font-size:large" dir=3D"ltr">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0return StrCaster<Out>{in};</div><div class=3D"gmail_default" st=
yle=3D"font-family:'arial narrow',sans-serif;font-size:large" dir=
=3D"ltr">};</div></div><div class=3D"gmail_extra"><div dir=3D"ltr"><br><div=
class=3D"gmail_quote">2015-10-08 1:33 GMT+03:30 Christopher Horvath <span =
dir=3D"ltr"><<a href=3D"mailto:blackencino@gmail.com" target=3D"_blank">=
blackencino@gmail.com</a>></span>:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D""=
>On Wed, Oct 7, 2015 at 2:57 PM, 'Nicholas Chapman' via ISO C++ Sta=
ndard - Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-propos=
als@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">As someone mention=
ed on the reddit thread, another possibility is to change the definition of=
reinterpret_cast to support the kind of stuff bit_cast would do:=C2=A0<a h=
ref=3D"https://www.reddit.com/r/programming/comments/3nmoo7/a_proposal_for_=
c_bit_cast/cvpocfe" target=3D"_blank">https://www.reddit.com/r/programming/=
comments/3nmoo7/a_proposal_for_c_bit_cast/cvpocfe</a><div>I don't know =
enough about the original design and intention of the C++ casts to say if t=
his is a good idea or not.</div><div>Does someone want to chime in on this?=
</div><div>Why doesn't reinterpret cast work like this in the first pla=
ce?</div><div><br></div></div></blockquote></span><div>I'm embarrassed =
to say that prior to this discussion, that's _exactly_ what I thought r=
einterpret_cast already did!=C2=A0</div><span class=3D""><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div></div><div><div>
<p></p>
-- <br>
<br>
--- <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@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></span></div><br></div></blockquote></div><div cla=
ss=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <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@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></div><br clear=3D"all"><div><br></div>-- <br><div class=3D"gma=
il_signature"><div dir=3D"rtl"><div><div dir=3D"ltr">how am I supposed to e=
nd the twisted road of=C2=A0 your hair in such a dark night??<br>unless the=
candle of your face does shed some light upon my way!!!<br></div></div></d=
iv></div>
</div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1149a17826e0bb052192e91f--
.
Author: Peter Koch Larsen <peter.koch.larsen@gmail.com>
Date: Thu, 8 Oct 2015 11:38:27 +0200
Raw View
This code is undefined behaviour, I believe (accessing elements in a
union that are not the type you put in).
/Peter
On 10/8/15, Farid Mehrabi <farid.mehrabi@gmail.com> wrote:
> template <typename Target>
> struct StrCaster{
> typedef
> constexpr StrCaster(Target const& src)
> : mData(src) {};
>
> template <typename Other>
> constexpr StrCaster(StrCaster<Other> const& init)
> {
> static_assert (sizeof (Other)==sizeof(Target));
> for(auto i=0;i<sizeof(Target);++i)
> mBytes[i]=init.mBytes[i];
> };
> constexpr operator Target(){return mData;};
> private:
> union{
> Target mData;
> char mBytes[sizeof(Target )];
> };
> };
>
> template <typename Out,typename In>
> constexpr Out bit_cast(In const val)
> {
> StrCaster<In> in {val};
> return StrCaster<Out>{in};
> };
>
> 2015-10-08 1:33 GMT+03:30 Christopher Horvath <blackencino@gmail.com>:
>
>>
>>
>> On Wed, Oct 7, 2015 at 2:57 PM, 'Nicholas Chapman' via ISO C++ Standard -
>> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>>> As someone mentioned on the reddit thread, another possibility is to
>>> change the definition of reinterpret_cast to support the kind of stuff
>>> bit_cast would do:
>>> https://www.reddit.com/r/programming/comments/3nmoo7/a_proposal_for_c_bit_cast/cvpocfe
>>> I don't know enough about the original design and intention of the C++
>>> casts to say if this is a good idea or not.
>>> Does someone want to chime in on this?
>>> Why doesn't reinterpret cast work like this in the first place?
>>>
>>> I'm embarrassed to say that prior to this discussion, that's _exactly_
>> what I thought reinterpret_cast already did!
>>
>>
>>> --
>>>
>>> ---
>>> 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.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
> --
> how am I supposed to end the twisted road of your hair in such a dark
> night??
> unless the candle of your face does shed some light upon my way!!!
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Thu, 8 Oct 2015 17:33:01 +0330
Raw View
--001a1149a17888239405219854db
Content-Type: text/plain; charset=UTF-8
except for character arrays; this one used to be standard sometime ago, iff
i am not mistaken. of course I am not certain about constexpr; it is
relatively too new for me.
regards,
FM.
2015-10-08 13:08 GMT+03:30 Peter Koch Larsen <peter.koch.larsen@gmail.com>:
> This code is undefined behaviour, I believe (accessing elements in a
> union that are not the type you put in).
>
> /Peter
>
> On 10/8/15, Farid Mehrabi <farid.mehrabi@gmail.com> wrote:
> > template <typename Target>
> > struct StrCaster{
> > typedef
> > constexpr StrCaster(Target const& src)
> > : mData(src) {};
> >
> > template <typename Other>
> > constexpr StrCaster(StrCaster<Other> const& init)
> > {
> > static_assert (sizeof (Other)==sizeof(Target));
> > for(auto i=0;i<sizeof(Target);++i)
> > mBytes[i]=init.mBytes[i];
> > };
> > constexpr operator Target(){return mData;};
> > private:
> > union{
> > Target mData;
> > char mBytes[sizeof(Target )];
> > };
> > };
> >
> > template <typename Out,typename In>
> > constexpr Out bit_cast(In const val)
> > {
> > StrCaster<In> in {val};
> > return StrCaster<Out>{in};
> > };
> >
> > 2015-10-08 1:33 GMT+03:30 Christopher Horvath <blackencino@gmail.com>:
> >
> >>
> >>
> >> On Wed, Oct 7, 2015 at 2:57 PM, 'Nicholas Chapman' via ISO C++ Standard
> -
> >> Future Proposals <std-proposals@isocpp.org> wrote:
> >>
> >>> As someone mentioned on the reddit thread, another possibility is to
> >>> change the definition of reinterpret_cast to support the kind of stuff
> >>> bit_cast would do:
> >>>
> https://www.reddit.com/r/programming/comments/3nmoo7/a_proposal_for_c_bit_cast/cvpocfe
> >>> I don't know enough about the original design and intention of the C++
> >>> casts to say if this is a good idea or not.
> >>> Does someone want to chime in on this?
> >>> Why doesn't reinterpret cast work like this in the first place?
> >>>
> >>> I'm embarrassed to say that prior to this discussion, that's _exactly_
> >> what I thought reinterpret_cast already did!
> >>
> >>
> >>> --
> >>>
> >>> ---
> >>> 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.
> >>> Visit this group at
> >>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
> >>>
> >>
> >> --
> >
> > ---
> > 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.
> > Visit this group at
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
> >
> >
> > --
> > how am I supposed to end the twisted road of your hair in such a dark
> > night??
> > unless the candle of your face does shed some light upon my way!!!
> >
> > --
> >
> > ---
> > 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.
> > Visit this group at
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
> >
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
how am I supposed to end the twisted road of your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1149a17888239405219854db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><div class=3D"gmail_default" style=3D"font-family:'ari=
al narrow',sans-serif;font-size:large" dir=3D"ltr">except for character=
arrays; this one used to be standard sometime ago, iff i am not mistaken. =
of course I am not certain about constexpr; it is relatively too new for me=
..</div><div class=3D"gmail_default" style=3D"font-family:'arial narrow&=
#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div><div class=3D"gmail_=
default" style=3D"font-family:'arial narrow',sans-serif;font-size:l=
arge" dir=3D"ltr">regards,</div><div class=3D"gmail_default" style=3D"font-=
family:'arial narrow',sans-serif;font-size:large" dir=3D"ltr">FM.</=
div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div di=
r=3D"ltr">2015-10-08 13:08 GMT+03:30 Peter Koch Larsen <span dir=3D"ltr">&l=
t;<a href=3D"mailto:peter.koch.larsen@gmail.com" target=3D"_blank">peter.ko=
ch.larsen@gmail.com</a>></span>:</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thi=
s code is undefined behaviour, I believe (accessing elements in a<br>
union that are not the type you put in).<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
/Peter<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
On 10/8/15, Farid Mehrabi <<a href=3D"mailto:farid.mehrabi@gmail.com">fa=
rid.mehrabi@gmail.com</a>> wrote:<br>
> template <typename Target><br>
> struct StrCaster{<br>
>=C2=A0 =C2=A0 =C2=A0 typedef<br>
>=C2=A0 =C2=A0 =C2=A0 constexpr StrCaster(Target const& src)<br>
>=C2=A0 =C2=A0 =C2=A0 :=C2=A0 =C2=A0 mData(src) {};<br>
><br>
>=C2=A0 =C2=A0 =C2=A0 template <typename Other><br>
>=C2=A0 =C2=A0 =C2=A0 constexpr StrCaster(StrCaster<Other> const&a=
mp; init)<br>
>=C2=A0 =C2=A0 =C2=A0 {<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0static_assert (sizeof (=
Other)=3D=3Dsizeof(Target));<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for(auto i=3D0;i<siz=
eof(Target);++i)<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mBytes[i]=
=3Dinit.mBytes[i];<br>
>=C2=A0 =C2=A0 =C2=A0 };<br>
> constexpr operator Target(){return mData;};<br>
> private:<br>
>=C2=A0 =C2=A0 =C2=A0 union{<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Target mData;<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0char mBytes[sizeof(Targ=
et )];<br>
>=C2=A0 =C2=A0 =C2=A0 };<br>
> };<br>
><br>
> template <typename Out,typename In><br>
> constexpr Out bit_cast(In const val)<br>
> {<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 StrCaster<In> in {val};<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return StrCaster<Out>{in};<br>
> };<br>
><br>
> 2015-10-08 1:33 GMT+03:30 Christopher Horvath <<a href=3D"mailto:bl=
ackencino@gmail.com">blackencino@gmail.com</a>>:<br>
><br>
>><br>
>><br>
>> On Wed, Oct 7, 2015 at 2:57 PM, 'Nicholas Chapman' via ISO=
C++ Standard -<br>
>> Future Proposals <<a href=3D"mailto:std-proposals@isocpp.org">s=
td-proposals@isocpp.org</a>> wrote:<br>
>><br>
>>> As someone mentioned on the reddit thread, another possibility=
is to<br>
>>> change the definition of reinterpret_cast to support the kind =
of stuff<br>
>>> bit_cast would do:<br>
>>> <a href=3D"https://www.reddit.com/r/programming/comments/3nmoo=
7/a_proposal_for_c_bit_cast/cvpocfe" rel=3D"noreferrer" target=3D"_blank">h=
ttps://www.reddit.com/r/programming/comments/3nmoo7/a_proposal_for_c_bit_ca=
st/cvpocfe</a><br>
>>> I don't know enough about the original design and intentio=
n of the C++<br>
>>> casts to say if this is a good idea or not.<br>
>>> Does someone want to chime in on this?<br>
>>> Why doesn't reinterpret cast work like this in the first p=
lace?<br>
>>><br>
>>> I'm embarrassed to say that prior to this discussion, that=
's _exactly_<br>
>> what I thought reinterpret_cast already did!<br>
>><br>
>><br>
>>> --<br>
>>><br>
>>> ---<br>
>>> You received this message because you are subscribed to the Go=
ogle<br>
>>> Groups<br>
>>> "ISO C++ Standard - Future Proposals" group.<br>
>>> To unsubscribe from this group and stop receiving emails from =
it, send<br>
>>> an<br>
>>> email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.=
org">std-proposals+unsubscribe@isocpp.org</a>.<br>
>>> To post to this group, send email to <a href=3D"mailto:std-pro=
posals@isocpp.org">std-proposals@isocpp.org</a>.<br>
>>> Visit this group at<br>
>>> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-pro=
posals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.com/a/is=
ocpp.org/group/std-proposals/</a>.<br>
>>><br>
>><br>
>> --<br>
><br>
> ---<br>
> You received this message because you are subscribed to the Google Gro=
ups<br>
> "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an<br>
> email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std=
-proposals+unsubscribe@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>
> Visit this group at<br>
> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
rel=3D"noreferrer" target=3D"_blank">http://groups.google.com/a/isocpp.org=
/group/std-proposals/</a>.<br>
><br>
><br>
> --<br>
> how am I supposed to end the twisted road of=C2=A0 your hair in such a=
dark<br>
> night??<br>
> unless the candle of your face does shed some light upon my way!!!<br>
><br>
> --<br>
><br>
> ---<br>
> You received this message because you are subscribed to the Google Gro=
ups<br>
> "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an<br>
> email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std=
-proposals+unsubscribe@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>
> Visit this group at<br>
> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
rel=3D"noreferrer" target=3D"_blank">http://groups.google.com/a/isocpp.org=
/group/std-proposals/</a>.<br>
><br>
<br>
--<br>
<br>
---<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@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"rtl"><div><div dir=3D"ltr">how a=
m I supposed to end the twisted road of=C2=A0 your hair in such a dark nigh=
t??<br>unless the candle of your face does shed some light upon my way!!!<b=
r></div></div></div></div>
</div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1149a17888239405219854db--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 08 Oct 2015 10:21:14 -0500
Raw View
On Thursday 08 October 2015 17:33:01 Farid Mehrabi wrote:
> except for character arrays; this one used to be standard sometime ago, iff
> i am not mistaken. of course I am not certain about constexpr; it is
> relatively too new for me.
That's a different undefined behaviour's exception. You're thinking of the
strict aliasing rule.
Accessing an inactive member of a union is undefined behaviour for any type,
except the active and the inactive are aggregates, share the same initial
sequence and you're accessing data in that sequence.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Myriachan <myriachan@gmail.com>
Date: Thu, 8 Oct 2015 15:48:16 -0700 (PDT)
Raw View
------=_Part_1708_1536573303.1444344496314
Content-Type: multipart/alternative;
boundary="----=_Part_1709_1417017254.1444344496314"
------=_Part_1709_1417017254.1444344496314
Content-Type: text/plain; charset=UTF-8
On Thursday, October 8, 2015 at 8:22:36 AM UTC-7, Thiago Macieira wrote:
>
> Accessing an inactive member of a union is undefined behaviour for any
> type,
> except the active and the inactive are aggregates, share the same initial
> sequence and you're accessing data in that sequence.
>
>
I wish that this were instead that accessing the inactive member of a union
is defined as reinterpreting the object representation as the new type.
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1709_1417017254.1444344496314
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, October 8, 2015 at 8:22:36 AM UTC-7, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Accessing an ina=
ctive member of a union is undefined behaviour for any type,=20
<br>except the active and the inactive are aggregates, share the same initi=
al=20
<br>sequence and you're accessing data in that sequence.
<br>
<br></blockquote><div><br>I wish that this were instead that accessing the =
inactive member of a union is defined as reinterpreting the object represen=
tation as the new type.<br><br>Melissa<br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1709_1417017254.1444344496314--
------=_Part_1708_1536573303.1444344496314--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 08 Oct 2015 16:22 -0700
Raw View
On Thursday 08 October 2015 15:48:16 Myriachan wrote:
> On Thursday, October 8, 2015 at 8:22:36 AM UTC-7, Thiago Macieira wrote:
> > Accessing an inactive member of a union is undefined behaviour for any
> > type,
> > except the active and the inactive are aggregates, share the same initial
> > sequence and you're accessing data in that sequence.
>
> I wish that this were instead that accessing the inactive member of a union
> is defined as reinterpreting the object representation as the new type.
There was some language in some draft, somewhere, that said exactly that. It
in fact blessed the GCC/Clang/Visual Studio behaviour. It's no longer there.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Fri, 9 Oct 2015 06:54:35 -0700 (PDT)
Raw View
------=_Part_1739_1936418456.1444398875111
Content-Type: multipart/alternative;
boundary="----=_Part_1740_918225030.1444398875111"
------=_Part_1740_918225030.1444398875111
Content-Type: text/plain; charset=UTF-8
On Friday, 9 October 2015 00:22:13 UTC+1, Thiago Macieira wrote:
>
> On Thursday 08 October 2015 15:48:16 Myriachan wrote:
> > On Thursday, October 8, 2015 at 8:22:36 AM UTC-7, Thiago Macieira wrote:
> > > Accessing an inactive member of a union is undefined behaviour for any
> > > type,
> > > except the active and the inactive are aggregates, share the same
> initial
> > > sequence and you're accessing data in that sequence.
> >
> > I wish that this were instead that accessing the inactive member of a
> union
> > is defined as reinterpreting the object representation as the new type.
>
Could you explain why? Isn't memcpy enough?
> There was some language in some draft, somewhere, that said exactly that.
> It
> in fact blessed the GCC/Clang/Visual Studio behaviour. It's no longer
> there.
>
Remember that the permissive behavior is defined in C (6.5.2.3/3, footnote
95). That said, even when compiling C, gcc and clang ignore it except in
the most trivial of cases (that is, they apply pointer aliasing rules
instead).
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1740_918225030.1444398875111
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, 9 October 2015 00:22:13 UTC+1, Thiago Macieira =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thursday 08 October =
2015 15:48:16 Myriachan wrote:
<br>> On Thursday, October 8, 2015 at 8:22:36 AM UTC-7, Thiago Macieira =
wrote:
<br>> > Accessing an inactive member of a union is undefined behaviou=
r for any
<br>> > type,
<br>> > except the active and the inactive are aggregates, share the =
same initial
<br>> > sequence and you're accessing data in that sequence.
<br>>=20
<br>> I wish that this were instead that accessing the inactive member o=
f a union
<br>> is defined as reinterpreting the object representation as the new =
type.
<br></blockquote><div><br></div><div>Could you explain why? Isn't memcp=
y enough?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">There was some language in some draft, somewhere, that said exactly that.=
It=20
<br>in fact blessed the GCC/Clang/Visual Studio behaviour. It's no long=
er there.
<br></blockquote><div><br></div><div>Remember that the permissive behavior =
is defined in C (6.5.2.3/3, footnote 95). That said, even when compiling C,=
gcc and clang ignore it except in the most trivial of cases (that is, they=
apply pointer aliasing rules instead).</div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1740_918225030.1444398875111--
------=_Part_1739_1936418456.1444398875111--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 09 Oct 2015 07:20:03 -0700
Raw View
On Friday 09 October 2015 06:54:35 Edward Catmur wrote:
> On Friday, 9 October 2015 00:22:13 UTC+1, Thiago Macieira wrote:
> > > I wish that this were instead that accessing the inactive member of a
> > > union
> > > is defined as reinterpreting the object representation as the new type.
>
> Could you explain why? Isn't memcpy enough?
It relies on the compiler properly optimising it. It doesn't always.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Jared Grubb <jared.grubb@gmail.com>
Date: Fri, 9 Oct 2015 08:52:07 -0700 (PDT)
Raw View
------=_Part_2784_1763903651.1444405927603
Content-Type: multipart/alternative;
boundary="----=_Part_2785_957046200.1444405927603"
------=_Part_2785_957046200.1444405927603
Content-Type: text/plain; charset=UTF-8
On Friday, October 9, 2015 at 7:20:07 AM UTC-7, Thiago Macieira wrote:
>
> On Friday 09 October 2015 06:54:35 Edward Catmur wrote:
> > On Friday, 9 October 2015 00:22:13 UTC+1, Thiago Macieira wrote:
> > > > I wish that this were instead that accessing the inactive member of
> a
> > > > union
> > > > is defined as reinterpreting the object representation as the new
> type.
> >
> > Could you explain why? Isn't memcpy enough?
>
> It relies on the compiler properly optimising it. It doesn't always.
>
I like this.
However, should this algorithm be SFINAE-protected with a
std::is_trivially_copyable check (I think this is the correct one)? You
could include a std::unsafe_bit_copy to operate without the SFINAE check.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2785_957046200.1444405927603
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, October 9, 2015 at 7:20:07 AM UTC-7, Th=
iago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Friday =
09 October 2015 06:54:35 Edward Catmur wrote:
<br>> On Friday, 9 October 2015 00:22:13 UTC+1, Thiago Macieira wrote:
<br>> > > I wish that this were instead that accessing the inactiv=
e member of a
<br>> > > union
<br>> > > is defined as reinterpreting the object representation a=
s the new type.
<br>>=20
<br>> Could you explain why? Isn't memcpy enough?
<br>
<br>It relies on the compiler properly optimising it. It doesn't always=
..
<br></blockquote><div><br>I like this. <br><br>However, should this algorit=
hm be SFINAE-protected with a std::is_trivially_copyable check (I think thi=
s is the correct one)? You could include a std::unsafe_bit_copy to operate =
without the SFINAE check.<br>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D&=
#39;http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46snt=
z\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">maciei=
ra.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\7=
5http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1Dowztw=
AHAKs80XSA';return true;" onclick=3D"this.href=3D'http://www.google=
..com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo=
5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2785_957046200.1444405927603--
------=_Part_2784_1763903651.1444405927603--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 10 Oct 2015 00:22:53 +0800
Raw View
> On 2015=E2=80=9310=E2=80=9309, at 11:52 PM, Jared Grubb <jared.grubb@gmai=
l.com> wrote:
>=20
> However, should this algorithm be SFINAE-protected with a std::is_trivial=
ly_copyable check (I think this is the correct one)? You could include a st=
d::unsafe_bit_copy to operate without the SFINAE check.
What=E2=80=99s the significance of trivial copyability when you=E2=80=99re =
reinterpreting the bits as some other type?
--=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/.
.
Author: Jared Grubb <jared.grubb@gmail.com>
Date: Fri, 9 Oct 2015 10:30:29 -0700 (PDT)
Raw View
------=_Part_2759_1070337613.1444411829888
Content-Type: multipart/alternative;
boundary="----=_Part_2760_1953708360.1444411829888"
------=_Part_2760_1953708360.1444411829888
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, October 9, 2015 at 9:22:59 AM UTC-7, David Krauss wrote:
>
>
> > On 2015=E2=80=9310=E2=80=9309, at 11:52 PM, Jared Grubb <jared...@gmail=
..com=20
> <javascript:>> wrote:=20
> >=20
> > However, should this algorithm be SFINAE-protected with a=20
> std::is_trivially_copyable check (I think this is the correct one)? You=
=20
> could include a std::unsafe_bit_copy to operate without the SFINAE check.=
=20
>
>
> What=E2=80=99s the significance of trivial copyability when you=E2=80=99r=
e reinterpreting=20
> the bits as some other type?=20
>
I believe that both the source and destination types must be=20
trivially-copyable in order for a memcpy operation between them to have any=
=20
safe meaning.
Although I'm not 100% certain that I'm picking the right trait here. Maybe=
=20
"is_pod" is the right SFINAE check here? Maybe it's a combination of a=20
couple? My point is that you need some SFINAE-check on this algorithm to=20
make it safe. I am having trouble thinking of an example where this would=
=20
prohibit something that would work otherwise (and in that case, add an=20
unsafe version but provide a safe one to double-check what programmers are=
=20
attempting).
--=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_2760_1953708360.1444411829888
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, October 9, 2015 at 9:22:59 AM UTC-7, Da=
vid Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>> On 2015=E2=80=9310=E2=80=9309, at 11:52 PM, Jared Grubb <<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"fLctIA4WDQAJ" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tr=
ue;" onclick=3D"this.href=3D'javascript:';return true;">jared...@gm=
ail.com</a>> wrote:
<br>>=20
<br>> However, should this algorithm be SFINAE-protected with a std::is_=
trivially_copyable check (I think this is the correct one)? You could inclu=
de a std::unsafe_bit_copy to operate without the SFINAE check.
<br>
<br>
<br>What=E2=80=99s the significance of trivial copyability when you=E2=80=
=99re reinterpreting the bits as some other type?
<br></blockquote><div><br>I believe that both the source and destination ty=
pes must be trivially-copyable in order for a memcpy operation between them=
to have any safe meaning.<br><br>Although I'm not 100% certain that I&=
#39;m picking the right trait here. Maybe "is_pod" is the right S=
FINAE check here? Maybe it's a combination of a couple? My point is tha=
t you need some SFINAE-check on this algorithm to make it safe. I am having=
trouble thinking of an example where this would prohibit something that wo=
uld work otherwise (and in that case, add an unsafe version but provide a s=
afe one to double-check what programmers are attempting).<br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2760_1953708360.1444411829888--
------=_Part_2759_1070337613.1444411829888--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Fri, 9 Oct 2015 11:24:44 -0700 (PDT)
Raw View
------=_Part_869_1741028249.1444415084107
Content-Type: multipart/alternative;
boundary="----=_Part_870_425606034.1444415084107"
------=_Part_870_425606034.1444415084107
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, 9 October 2015 18:30:30 UTC+1, Jared Grubb wrote:
>
>
>
> On Friday, October 9, 2015 at 9:22:59 AM UTC-7, David Krauss wrote:
>>
>>
>> > On 2015=E2=80=9310=E2=80=9309, at 11:52 PM, Jared Grubb <jared...@gmai=
l.com> wrote:=20
>> >=20
>> > However, should this algorithm be SFINAE-protected with a=20
>> std::is_trivially_copyable check (I think this is the correct one)? You=
=20
>> could include a std::unsafe_bit_copy to operate without the SFINAE check=
..=20
>>
>>
>> What=E2=80=99s the significance of trivial copyability when you=E2=80=99=
re reinterpreting=20
>> the bits as some other type?=20
>>
>
> I believe that both the source and destination types must be=20
> trivially-copyable in order for a memcpy operation between them to have a=
ny=20
> safe meaning.
>
Yes; see [basic.types]/2-4.
=20
> Although I'm not 100% certain that I'm picking the right trait here. Mayb=
e=20
> "is_pod" is the right SFINAE check here? Maybe it's a combination of a=20
> couple? My point is that you need some SFINAE-check on this algorithm to=
=20
> make it safe. I am having trouble thinking of an example where this would=
=20
> prohibit something that would work otherwise (and in that case, add an=20
> unsafe version but provide a safe one to double-check what programmers ar=
e=20
> attempting).
>
For the obvious implementation to be valid, you'd need is_trivial (which=20
implies is_trivially_copyable) on the destination type. That still doesn't=
=20
guarantee that the result won't be UB; if the destination type is or=20
contains a primitive other than an unsigned narrow character type the=20
result could trap. There's also cv qualifiers and reference data members to=
=20
consider (standayd-layout precludes the latter, but not the former).
--=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_870_425606034.1444415084107
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div><br></div><div>On Friday, 9 October 2015 18:30:30 UTC+1, Jared Grubb =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br=
>On Friday, October 9, 2015 at 9:22:59 AM UTC-7, David Krauss wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<br>> On 2015=E2=80=9310=E2=80=9309, at 11:52 PM, Jared Grubb <<a rel=
=3D"nofollow">jared...@gmail.com</a>> wrote:
<br>>=20
<br>> However, should this algorithm be SFINAE-protected with a std::is_=
trivially_copyable check (I think this is the correct one)? You could inclu=
de a std::unsafe_bit_copy to operate without the SFINAE check.
<br>
<br>
<br>What=E2=80=99s the significance of trivial copyability when you=E2=80=
=99re reinterpreting the bits as some other type?
<br></blockquote><div><br>I believe that both the source and destination ty=
pes must be trivially-copyable in order for a memcpy operation between them=
to have any safe meaning.<br></div></div></blockquote><div><br></div><div>=
Yes; see [basic.types]/2-4.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div>Although I'm not 100% certain=
that I'm picking the right trait here. Maybe "is_pod" is the=
right SFINAE check here? Maybe it's a combination of a couple? My poin=
t is that you need some SFINAE-check on this algorithm to make it safe. I a=
m having trouble thinking of an example where this would prohibit something=
that would work otherwise (and in that case, add an unsafe version but pro=
vide a safe one to double-check what programmers are attempting).<br></div>=
</div></blockquote><div><br></div><div>For the obvious implementation to be=
valid, you'd need is_trivial (which implies is_trivially_copyable) on =
the destination type. That still doesn't guarantee that the result won&=
#39;t be UB; if the destination type is or contains a primitive other than =
an unsigned narrow character type the result could trap. There's also c=
v qualifiers and reference data members to consider (standayd-layout preclu=
des the latter, but not the former).</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_870_425606034.1444415084107--
------=_Part_869_1741028249.1444415084107--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 9 Oct 2015 12:47:23 -0700 (PDT)
Raw View
------=_Part_2162_903499293.1444420043264
Content-Type: multipart/alternative;
boundary="----=_Part_2163_1355733483.1444420043264"
------=_Part_2163_1355733483.1444420043264
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, October 9, 2015 at 1:30:30 PM UTC-4, Jared Grubb wrote:
>
> On Friday, October 9, 2015 at 9:22:59 AM UTC-7, David Krauss wrote:
>>
>>
>> > On 2015=E2=80=9310=E2=80=9309, at 11:52 PM, Jared Grubb <jared...@gmai=
l.com> wrote:=20
>> >=20
>> > However, should this algorithm be SFINAE-protected with a=20
>> std::is_trivially_copyable check (I think this is the correct one)? You=
=20
>> could include a std::unsafe_bit_copy to operate without the SFINAE check=
..=20
>>
>>
>> What=E2=80=99s the significance of trivial copyability when you=E2=80=99=
re reinterpreting=20
>> the bits as some other type?=20
>>
>
> I believe that both the source and destination types must be=20
> trivially-copyable in order for a memcpy operation between them to have a=
ny=20
> safe meaning.
>
> Although I'm not 100% certain that I'm picking the right trait here. Mayb=
e=20
> "is_pod" is the right SFINAE check here? Maybe it's a combination of a=20
> couple? My point is that you need some SFINAE-check on this algorithm to=
=20
> make it safe. I am having trouble thinking of an example where this would=
=20
> prohibit something that would work otherwise (and in that case, add an=20
> unsafe version but provide a safe one to double-check what programmers ar=
e=20
> attempting).
>
I'm pretty sure `is_pod` is more strict than is absolutely necessary.
Trivial copyability is needed for `memcpy` to actually produce defined=20
results. However, trivial copyability alone only allows copying between two=
=20
objects of the same type. If you want to memcpy between two objects of=20
different types, then in order to get defined behavior, the types must be=
=20
layout compatible.
Of course, the OP clearly does not care about what is and is not=20
well-defined. Binary int-to-float conversions do not produce=20
standard-defined behavior. So if the goal is to make bit_copy<int, float>=
=20
actually work, you don't care about what is technically legal C++.
I liked the idea above about having `bit_copy` and `unsafe_bit_copy`. The=
=20
former requires layout compatibility between the types, and the latter=20
doesn't care.
Then again, I'm having trouble coming up with reasons when I would need to=
=20
use the safe `bit_copy`. I guess it would be a better description of what=
=20
you intend, since you'd use that rather than raw `memcpy` for copying=20
compatible types.
--=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_2163_1355733483.1444420043264
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, October 9, 2015 at 1:30:30 PM UTC-4, Jared Grubb wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Friday, October 9, =
2015 at 9:22:59 AM UTC-7, David Krauss wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex">
<br>> On 2015=E2=80=9310=E2=80=9309, at 11:52 PM, Jared Grubb <<a rel=
=3D"nofollow">jared...@gmail.com</a>> wrote:
<br>>=20
<br>> However, should this algorithm be SFINAE-protected with a std::is_=
trivially_copyable check (I think this is the correct one)? You could inclu=
de a std::unsafe_bit_copy to operate without the SFINAE check.
<br>
<br>
<br>What=E2=80=99s the significance of trivial copyability when you=E2=80=
=99re reinterpreting the bits as some other type?
<br></blockquote><div><br>I believe that both the source and destination ty=
pes must be trivially-copyable in order for a memcpy operation between them=
to have any safe meaning.<br><br>Although I'm not 100% certain that I&=
#39;m picking the right trait here. Maybe "is_pod" is the right S=
FINAE check here? Maybe it's a combination of a couple? My point is tha=
t you need some SFINAE-check on this algorithm to make it safe. I am having=
trouble thinking of an example where this would prohibit something that wo=
uld work otherwise (and in that case, add an unsafe version but provide a s=
afe one to double-check what programmers are attempting).<br></div></div></=
blockquote><div><br>I'm pretty sure `is_pod` is more strict than is abs=
olutely necessary.<br><br>Trivial copyability is needed for `memcpy` to act=
ually produce defined results. However, trivial copyability alone only allo=
ws copying between two objects of the same type. If you want to memcpy betw=
een two objects of different types, then in order to get defined behavior, =
the types must be layout compatible.<br><br>Of course, the OP clearly does =
not care about what is and is not well-defined. Binary int-to-float convers=
ions do not produce standard-defined behavior. So if the goal is to make bi=
t_copy<int, float> actually work, you don't care about what is te=
chnically legal C++.<br><br>I liked the idea above about having `bit_copy` =
and `unsafe_bit_copy`. The former requires layout compatibility between the=
types, and the latter doesn't care.<br><br>Then again, I'm having =
trouble coming up with reasons when I would need to use the safe `bit_copy`=
.. I guess it would be a better description of what you intend, since you=
9;d use that rather than raw `memcpy` for copying compatible types.<br></di=
v>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2163_1355733483.1444420043264--
------=_Part_2162_903499293.1444420043264--
.
Author: Myriachan <myriachan@gmail.com>
Date: Mon, 12 Oct 2015 13:16:10 -0700 (PDT)
Raw View
------=_Part_1293_2043933131.1444680970715
Content-Type: multipart/alternative;
boundary="----=_Part_1294_539392369.1444680970715"
------=_Part_1294_539392369.1444680970715
Content-Type: text/plain; charset=UTF-8
On Friday, October 9, 2015 at 12:47:23 PM UTC-7, Nicol Bolas wrote:
>
>
> I'm pretty sure `is_pod` is more strict than is absolutely necessary.
>
> Trivial copyability is needed for `memcpy` to actually produce defined
> results. However, trivial copyability alone only allows copying between two
> objects of the same type. If you want to memcpy between two objects of
> different types, then in order to get defined behavior, the types must be
> layout compatible.
>
> Of course, the OP clearly does not care about what is and is not
> well-defined. Binary int-to-float conversions do not produce
> standard-defined behavior. So if the goal is to make bit_copy<int, float>
> actually work, you don't care about what is technically legal C++.
>
>
What's wrong with defining bit_cast/bit_copy such that the results of such
a cast as implementation-defined, with a non-normative note similar to that
of [expr.reinterpret.cast]/4: "A pointer can be explicitly converted to any
integral type large enough to hold it. The mapping function is
implementation-defined. [*Note:* It is intended to be unsurprising to
those who know the addressing structure of the underlying machine. -- *end
note*]"? That is, the result of bit_cast would be implementation-defined,
but its result should be unsurprising to those with knowledge of the type
of the machine. bit_casting std::uint32_t(0x3F800000) to float on an x86
implementation and getting 1.0f would be such an "unsurprising result" for
those knowing that the machine is an x86.
The Standard can change to define whatever the Committee feels necessary.
Saying that something is undefined behavior as a reason to dismiss a
proposal is circular logic to me.
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1294_539392369.1444680970715
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, October 9, 2015 at 12:47:23 PM UTC-7, Nicol Bol=
as wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><div>I'm pret=
ty sure `is_pod` is more strict than is absolutely necessary.<br><br>Trivia=
l copyability is needed for `memcpy` to actually produce defined results. H=
owever, trivial copyability alone only allows copying between two objects o=
f the same type. If you want to memcpy between two objects of different typ=
es, then in order to get defined behavior, the types must be layout compati=
ble.<br><br>Of course, the OP clearly does not care about what is and is no=
t well-defined. Binary int-to-float conversions do not produce standard-def=
ined behavior. So if the goal is to make bit_copy<int, float> actuall=
y work, you don't care about what is technically legal C++.<br><br></di=
v></blockquote><div><br>What's wrong with defining <span style=3D"font-=
family: courier new,monospace;">bit_cast</span>/<span style=3D"font-family:=
courier new,monospace;">bit_copy</span> such that the results of such a ca=
st as implementation-defined, with a non-normative note similar to that of =
[expr.reinterpret.cast]/4: "A pointer can be explicitly converted to a=
ny integral type large enough to hold it.=C2=A0 The mapping function is imp=
lementation-defined.=C2=A0 [<i>Note:</i> It is intended to be unsurprising =
to those who know the addressing structure of the underlying machine. -- <i=
>end note</i>]"?=C2=A0 That is, the result of <span style=3D"font-fami=
ly: courier new,monospace;">bit_cast</span> would be implementation-defined=
, but its result should be unsurprising to those with knowledge of the type=
of the machine.=C2=A0 <span style=3D"font-family: courier new,monospace;">=
bit_cast</span>ing <span style=3D"font-family: courier new,monospace;">std:=
:uint32_t(0x3F800000)</span> to <span style=3D"font-family: courier new,mon=
ospace;">float</span> on an x86 implementation and getting <span style=3D"f=
ont-family: courier new,monospace;">1.0f</span> would be such an "unsu=
rprising result" for those knowing that the machine is an x86.<br><br>=
The Standard can change to define whatever the Committee feels necessary.=
=C2=A0 Saying that something is undefined behavior as a reason to dismiss a=
proposal is circular logic to me.<br><br>Melissa<br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1294_539392369.1444680970715--
------=_Part_1293_2043933131.1444680970715--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 12 Oct 2015 22:20:26 +0100
Raw View
--089e013d171ce1e1a70521eee596
Content-Type: text/plain; charset=UTF-8
The standard can't ensure every bit_cast is defined, not even when the
destination type is trivially copyable; the source value could be the
object representation of a trap representation in the target type.
It's still possible to define bit_cast without reference to memcpy, though:
something like "If the object representation of the source value contains
the value representation of a value of the target type, returns that value;
otherwise, the result is undefined." That gets us the expected behavior on
x86 without restricting other platforms.
On 12 Oct 2015 21:16, "Myriachan" <myriachan@gmail.com> wrote:
> On Friday, October 9, 2015 at 12:47:23 PM UTC-7, Nicol Bolas wrote:
>>
>>
>> I'm pretty sure `is_pod` is more strict than is absolutely necessary.
>>
>> Trivial copyability is needed for `memcpy` to actually produce defined
>> results. However, trivial copyability alone only allows copying between two
>> objects of the same type. If you want to memcpy between two objects of
>> different types, then in order to get defined behavior, the types must be
>> layout compatible.
>>
>> Of course, the OP clearly does not care about what is and is not
>> well-defined. Binary int-to-float conversions do not produce
>> standard-defined behavior. So if the goal is to make bit_copy<int, float>
>> actually work, you don't care about what is technically legal C++.
>>
>>
> What's wrong with defining bit_cast/bit_copy such that the results of
> such a cast as implementation-defined, with a non-normative note similar to
> that of [expr.reinterpret.cast]/4: "A pointer can be explicitly converted
> to any integral type large enough to hold it. The mapping function is
> implementation-defined. [*Note:* It is intended to be unsurprising to
> those who know the addressing structure of the underlying machine. -- *end
> note*]"? That is, the result of bit_cast would be
> implementation-defined, but its result should be unsurprising to those with
> knowledge of the type of the machine. bit_casting
> std::uint32_t(0x3F800000) to float on an x86 implementation and getting
> 1.0f would be such an "unsurprising result" for those knowing that the
> machine is an x86.
>
> The Standard can change to define whatever the Committee feels necessary.
> Saying that something is undefined behavior as a reason to dismiss a
> proposal is circular logic to me.
>
> Melissa
>
> --
>
> ---
> 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/3H6-V9_qVmQ/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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e013d171ce1e1a70521eee596
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">The standard can't ensure every bit_cast is defined, not=
even when the destination type is trivially copyable; the source value cou=
ld be the object representation of a trap representation in the target type=
.. </p>
<p dir=3D"ltr">It's still possible to define bit_cast without reference=
to memcpy, though: something like "If the object representation of th=
e source value contains the value representation of a value of the target t=
ype, returns that value; otherwise, the result is undefined." That get=
s us the expected behavior on x86 without restricting other platforms.</p>
<div class=3D"gmail_quote">On 12 Oct 2015 21:16, "Myriachan" <=
<a href=3D"mailto:myriachan@gmail.com">myriachan@gmail.com</a>> wrote:<b=
r type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On F=
riday, October 9, 2015 at 12:47:23 PM UTC-7, Nicol Bolas wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><br><div>I'm pretty sure `is_pod` is more s=
trict than is absolutely necessary.<br><br>Trivial copyability is needed fo=
r `memcpy` to actually produce defined results. However, trivial copyabilit=
y alone only allows copying between two objects of the same type. If you wa=
nt to memcpy between two objects of different types, then in order to get d=
efined behavior, the types must be layout compatible.<br><br>Of course, the=
OP clearly does not care about what is and is not well-defined. Binary int=
-to-float conversions do not produce standard-defined behavior. So if the g=
oal is to make bit_copy<int, float> actually work, you don't care=
about what is technically legal C++.<br><br></div></blockquote><div><br>Wh=
at's wrong with defining <span style=3D"font-family:courier new,monospa=
ce">bit_cast</span>/<span style=3D"font-family:courier new,monospace">bit_c=
opy</span> such that the results of such a cast as implementation-defined, =
with a non-normative note similar to that of [expr.reinterpret.cast]/4: &qu=
ot;A pointer can be explicitly converted to any integral type large enough =
to hold it.=C2=A0 The mapping function is implementation-defined.=C2=A0 [<i=
>Note:</i> It is intended to be unsurprising to those who know the addressi=
ng structure of the underlying machine. -- <i>end note</i>]"?=C2=A0 Th=
at is, the result of <span style=3D"font-family:courier new,monospace">bit_=
cast</span> would be implementation-defined, but its result should be unsur=
prising to those with knowledge of the type of the machine.=C2=A0 <span sty=
le=3D"font-family:courier new,monospace">bit_cast</span>ing <span style=3D"=
font-family:courier new,monospace">std::uint32_t(0x3F800000)</span> to <spa=
n style=3D"font-family:courier new,monospace">float</span> on an x86 implem=
entation and getting <span style=3D"font-family:courier new,monospace">1.0f=
</span> would be such an "unsurprising result" for those knowing =
that the machine is an x86.<br><br>The Standard can change to define whatev=
er the Committee feels necessary.=C2=A0 Saying that something is undefined =
behavior as a reason to dismiss a proposal is circular logic to me.<br><br>=
Melissa<br></div></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le 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/3H6-V9_qVmQ/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/3H6-V9_qVmQ=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e013d171ce1e1a70521eee596--
.
Author: Myriachan <myriachan@gmail.com>
Date: Mon, 12 Oct 2015 16:36:27 -0700 (PDT)
Raw View
------=_Part_1451_1195688640.1444692987843
Content-Type: multipart/alternative;
boundary="----=_Part_1452_99336929.1444692987844"
------=_Part_1452_99336929.1444692987844
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, October 12, 2015 at 2:20:27 PM UTC-7, Edward Catmur wrote:
>
> The standard can't ensure every bit_cast is defined, not even when the=20
> destination type is trivially copyable; the source value could be the=20
> object representation of a trap representation in the target type.=20
>
That is true for the x86 as well, if floating-point exceptions are enabled=
=20
and you make a NaN or something via bit_cast.
=20
> It's still possible to define bit_cast without reference to memcpy,=20
> though: something like "If the object representation of the source value=
=20
> contains the value representation of a value of the target type, returns=
=20
> that value; otherwise, the result is undefined." That gets us the expecte=
d=20
> behavior on x86 without restricting other platforms.
>
I really like that wording, though I think you meant "object" in one place=
=20
you said "value". How about this sort of wording?
template <class Target, class Source>
Target bit_cast(const Source &src);
1. Requires: Target and Source shall meet the requirements of=20
TriviallyCopyable, and sizeof(Target) shall equal sizeof(Source). [*Note: =
*This=20
means that sizeof(Target) and sizeof(Source) must be defined; i.e., Target=
=20
and Source cannot be "array of unknown bound of T" for some type T. =E2=80=
=94 *end=20
note*]
2. Returns: If the object representation of src equals the object=20
representation of some value t of type Target, then t. Otherwise, the=20
behavior is undefined. [*Note: *Where defined, this is equivalent to the=
=20
effect of std::memcpy. =E2=80=94 *end note*]
3. Complexity: At most *O*(*N*), where *N* has the value sizeof(Target).
4. Remarks: Target and Source need not have the same alignment requirements=
..
On 12 Oct 2015 21:16, "Myriachan" <myri...@gmail.com <javascript:>> wrote:
>
>> On Friday, October 9, 2015 at 12:47:23 PM UTC-7, Nicol Bolas wrote:
>>>
>>>
>>> I'm pretty sure `is_pod` is more strict than is absolutely necessary.
>>>
>>> Trivial copyability is needed for `memcpy` to actually produce defined=
=20
>>> results. However, trivial copyability alone only allows copying between=
two=20
>>> objects of the same type. If you want to memcpy between two objects of=
=20
>>> different types, then in order to get defined behavior, the types must =
be=20
>>> layout compatible.
>>>
>>> Of course, the OP clearly does not care about what is and is not=20
>>> well-defined. Binary int-to-float conversions do not produce=20
>>> standard-defined behavior. So if the goal is to make bit_copy<int, floa=
t>=20
>>> actually work, you don't care about what is technically legal C++.
>>>
>>>
>> What's wrong with defining bit_cast/bit_copy such that the results of=20
>> such a cast as implementation-defined, with a non-normative note similar=
to=20
>> that of [expr.reinterpret.cast]/4: "A pointer can be explicitly converte=
d=20
>> to any integral type large enough to hold it. The mapping function is=
=20
>> implementation-defined. [*Note:* It is intended to be unsurprising to=
=20
>> those who know the addressing structure of the underlying machine. -- *e=
nd=20
>> note*]"? That is, the result of bit_cast would be=20
>> implementation-defined, but its result should be unsurprising to those w=
ith=20
>> knowledge of the type of the machine. bit_casting=20
>> std::uint32_t(0x3F800000) to float on an x86 implementation and getting=
=20
>> 1.0f would be such an "unsurprising result" for those knowing that the=
=20
>> machine is an x86.
>>
>> The Standard can change to define whatever the Committee feels=20
>> necessary. Saying that something is undefined behavior as a reason to=
=20
>> dismiss a proposal is circular logic to me.
>>
>> Melissa
>>
>> --=20
>>
>> ---=20
>> You received this message because you are subscribed to a topic in the=
=20
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit=20
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/3H6-V9_qVmQ=
/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to=20
>> std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
--=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_1452_99336929.1444692987844
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, October 12, 2015 at 2:20:27 PM UTC-7, Edward Ca=
tmur wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">The =
standard can't ensure every bit_cast is defined, not even when the dest=
ination type is trivially copyable; the source value could be the object re=
presentation of a trap representation in the target type. </p></blockquote>=
<div><br>That is true for the x86 as well, if floating-point exceptions are=
enabled and you make a NaN or something via bit_cast.<br>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">It's still possible to define bit_cast without reference=
to memcpy, though: something like "If the object representation of th=
e source value contains the value representation of a value of the target t=
ype, returns that value; otherwise, the result is undefined." That get=
s us the expected behavior on x86 without restricting other platforms.</p><=
/blockquote><div><br>I really like that wording, though I think you meant &=
quot;object" in one place you said "value".=C2=A0 How about =
this sort of wording?<br><br><div class=3D"prettyprint" style=3D"background=
-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style:=
solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">template</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">Target</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" clas=
s=3D"styled-by-prettify">Source</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Target</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> bit_cast</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Sour=
ce</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">src</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code></div>=
<br>1. Requires: <span style=3D"font-family: courier new,monospace;">Target=
</span> and <span style=3D"font-family: courier new,monospace;">Source</spa=
n> shall meet the requirements of <span style=3D"font-family: courier new,m=
onospace;">TriviallyCopyable</span>, and <span style=3D"font-family: courie=
r new,monospace;">sizeof(Target)</span> shall equal <span style=3D"font-fam=
ily: courier new,monospace;">sizeof(Source)</span>.=C2=A0 [<i>Note: </i>Thi=
s means that <span style=3D"font-family: courier new,monospace;">sizeof(Tar=
get)</span> and <span style=3D"font-family: courier new,monospace;">sizeof(=
Source)</span> must be defined; i.e., <span style=3D"font-family: courier n=
ew,monospace;">Target</span> and <span style=3D"font-family: courier new,mo=
nospace;">Source</span> cannot be "array of unknown bound of <span sty=
le=3D"font-family: courier new,monospace;">T</span>" for some type <sp=
an style=3D"font-family: courier new,monospace;">T</span>. =E2=80=94 <i>end=
note</i>]<br>2. Returns: If the object representation of <span style=3D"fo=
nt-family: courier new,monospace;">src</span> equals the object representat=
ion of some value <span style=3D"font-family: courier new,monospace;">t</sp=
an> of type Target, then <span style=3D"font-family: courier new,monospace;=
">t</span>.=C2=A0 Otherwise, the behavior is undefined.=C2=A0 [<i>Note: </i=
>Where defined, this is equivalent to the effect of <span style=3D"font-fam=
ily: courier new,monospace;">std::memcpy</span>. =E2=80=94 <i>end note</i>]=
<br>3. Complexity: At most <i>O</i>(<i>N</i>), where <i>N</i> has the value=
<span style=3D"font-family: courier new,monospace;">sizeof(Target)</span>.=
<br>4. Remarks: <span style=3D"font-family: courier new,monospace;">Target<=
/span> and <span style=3D"font-family: courier new,monospace;">Source</span=
> need not have the same alignment requirements.<br><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;">
<div class=3D"gmail_quote">On 12 Oct 2015 21:16, "Myriachan" <=
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"gxDsdQcS=
DgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">myri.=
...@gmail.com</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr">On Friday, October 9, 2015 at 12:47:23 PM UTC-7, N=
icol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div>I'm p=
retty sure `is_pod` is more strict than is absolutely necessary.<br><br>Tri=
vial copyability is needed for `memcpy` to actually produce defined results=
.. However, trivial copyability alone only allows copying between two object=
s of the same type. If you want to memcpy between two objects of different =
types, then in order to get defined behavior, the types must be layout comp=
atible.<br><br>Of course, the OP clearly does not care about what is and is=
not well-defined. Binary int-to-float conversions do not produce standard-=
defined behavior. So if the goal is to make bit_copy<int, float> actu=
ally work, you don't care about what is technically legal C++.<br><br><=
/div></blockquote><div><br>What's wrong with defining <span style=3D"fo=
nt-family:courier new,monospace">bit_cast</span>/<span style=3D"font-family=
:courier new,monospace">bit_copy</span> such that the results of such a cas=
t as implementation-defined, with a non-normative note similar to that of [=
expr.reinterpret.cast]/4: "A pointer can be explicitly converted to an=
y integral type large enough to hold it.=C2=A0 The mapping function is impl=
ementation-defined.=C2=A0 [<i>Note:</i> It is intended to be unsurprising t=
o those who know the addressing structure of the underlying machine. -- <i>=
end note</i>]"?=C2=A0 That is, the result of <span style=3D"font-famil=
y:courier new,monospace">bit_cast</span> would be implementation-defined, b=
ut its result should be unsurprising to those with knowledge of the type of=
the machine.=C2=A0 <span style=3D"font-family:courier new,monospace">bit_c=
ast</span>ing <span style=3D"font-family:courier new,monospace">std::uint32=
_t(0x3F800000)</span> to <span style=3D"font-family:courier new,monospace">=
float</span> on an x86 implementation and getting <span style=3D"font-famil=
y:courier new,monospace">1.0f</span> would be such an "unsurprising re=
sult" for those knowing that the machine is an x86.<br><br>The Standar=
d can change to define whatever the Committee feels necessary.=C2=A0 Saying=
that something is undefined behavior as a reason to dismiss a proposal is =
circular logic to me.<br><br>Melissa<br></div></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le 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/3H6-V9_qVmQ/unsubscribe" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.c=
om/a/isocpp.org/d/topic/std-proposals/3H6-V9_qVmQ/unsubscribe';return t=
rue;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/=
topic/std-proposals/3H6-V9_qVmQ/unsubscribe';return true;">https://grou=
ps.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/3H6-V9_qVmQ/<wbr=
>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"gxDsdQcSDgAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;">std-proposal=
....@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"gxDsdQcSDgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';ret=
urn true;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.or=
g/group/std-proposals/';return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</blockquote></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1452_99336929.1444692987844--
------=_Part_1451_1195688640.1444692987843--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 13 Oct 2015 15:52:06 +0100
Raw View
--001a1130d1dcf440c20521fd9666
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Yes, that sounds great. I don't think it's actually necessary to constrain
Source in any way, only Target; for example, it would be useful (for
debugging/pedagogical purposes at least) to be able to write:
struct A { virtual ~A() =3D default; };
int main() { std::cout << bit_cast<void*>(A{}) << '\n'; }
On Tue, Oct 13, 2015 at 12:36 AM, Myriachan <myriachan@gmail.com> wrote:
> On Monday, October 12, 2015 at 2:20:27 PM UTC-7, Edward Catmur wrote:
>>
>> The standard can't ensure every bit_cast is defined, not even when the
>> destination type is trivially copyable; the source value could be the
>> object representation of a trap representation in the target type.
>>
>
> That is true for the x86 as well, if floating-point exceptions are enable=
d
> and you make a NaN or something via bit_cast.
>
>
>> It's still possible to define bit_cast without reference to memcpy,
>> though: something like "If the object representation of the source value
>> contains the value representation of a value of the target type, returns
>> that value; otherwise, the result is undefined." That gets us the expect=
ed
>> behavior on x86 without restricting other platforms.
>>
>
> I really like that wording, though I think you meant "object" in one plac=
e
> you said "value". How about this sort of wording?
>
> template <class Target, class Source>
> Target bit_cast(const Source &src);
>
> 1. Requires: Target and Source shall meet the requirements of
> TriviallyCopyable, and sizeof(Target) shall equal sizeof(Source). [*Note=
:
> *This means that sizeof(Target) and sizeof(Source) must be defined; i.e.,
> Target and Source cannot be "array of unknown bound of T" for some type T=
..
> =E2=80=94 *end note*]
> 2. Returns: If the object representation of src equals the object
> representation of some value t of type Target, then t. Otherwise, the
> behavior is undefined. [*Note: *Where defined, this is equivalent to the
> effect of std::memcpy. =E2=80=94 *end note*]
> 3. Complexity: At most *O*(*N*), where *N* has the value sizeof(Target).
> 4. Remarks: Target and Source need not have the same alignment
> requirements.
>
> On 12 Oct 2015 21:16, "Myriachan" <myri...@gmail.com> wrote:
>>
>>> On Friday, October 9, 2015 at 12:47:23 PM UTC-7, Nicol Bolas wrote:
>>>>
>>>>
>>>> I'm pretty sure `is_pod` is more strict than is absolutely necessary.
>>>>
>>>> Trivial copyability is needed for `memcpy` to actually produce defined
>>>> results. However, trivial copyability alone only allows copying betwee=
n two
>>>> objects of the same type. If you want to memcpy between two objects of
>>>> different types, then in order to get defined behavior, the types must=
be
>>>> layout compatible.
>>>>
>>>> Of course, the OP clearly does not care about what is and is not
>>>> well-defined. Binary int-to-float conversions do not produce
>>>> standard-defined behavior. So if the goal is to make bit_copy<int, flo=
at>
>>>> actually work, you don't care about what is technically legal C++.
>>>>
>>>>
>>> What's wrong with defining bit_cast/bit_copy such that the results of
>>> such a cast as implementation-defined, with a non-normative note simila=
r to
>>> that of [expr.reinterpret.cast]/4: "A pointer can be explicitly convert=
ed
>>> to any integral type large enough to hold it. The mapping function is
>>> implementation-defined. [*Note:* It is intended to be unsurprising to
>>> those who know the addressing structure of the underlying machine. -- *=
end
>>> note*]"? That is, the result of bit_cast would be
>>> implementation-defined, but its result should be unsurprising to those =
with
>>> knowledge of the type of the machine. bit_casting
>>> std::uint32_t(0x3F800000) to float on an x86 implementation and getting
>>> 1.0f would be such an "unsurprising result" for those knowing that the
>>> machine is an x86.
>>>
>>> The Standard can change to define whatever the Committee feels
>>> necessary. Saying that something is undefined behavior as a reason to
>>> dismiss a proposal is circular logic to me.
>>>
>>> Melissa
>>>
>>> --
>>>
>>> ---
>>> 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/3H6-V9_qVm=
Q/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to
>>> std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>> --
>
> ---
> 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/3H6-V9_qVmQ/=
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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=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/.
--001a1130d1dcf440c20521fd9666
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yes, that sounds great. I don't think it's actuall=
y necessary to constrain <font face=3D"monospace, monospace">Source</font> =
in any way, only <font face=3D"monospace, monospace">Target</font>; for exa=
mple, it would be useful (for debugging/pedagogical purposes at least) to b=
e able to write:<div><br></div><div><font face=3D"monospace, monospace">str=
uct A { virtual ~A() =3D default; };</font></div><div><font face=3D"monospa=
ce, monospace">int main() { std::cout << bit_cast<void*>(A{}) &=
lt;< '\n'; }</font></div></div><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">On Tue, Oct 13, 2015 at 12:36 AM, Myriachan <span =
dir=3D"ltr"><<a href=3D"mailto:myriachan@gmail.com" target=3D"_blank">my=
riachan@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"><span class=3D"">On Monday, October 12, 2015 at 2:20:27 PM =
UTC-7, Edward Catmur wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=
=3D"ltr">The standard can't ensure every bit_cast is defined, not even =
when the destination type is trivially copyable; the source value could be =
the object representation of a trap representation in the target type. </p>=
</blockquote></span><div><br>That is true for the x86 as well, if floating-=
point exceptions are enabled and you make a NaN or something via bit_cast.<=
br>=C2=A0</div><span class=3D""><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">It's still possible to define bit_cast without reference=
to memcpy, though: something like "If the object representation of th=
e source value contains the value representation of a value of the target t=
ype, returns that value; otherwise, the result is undefined." That get=
s us the expected behavior on x86 without restricting other platforms.</p><=
/blockquote></span><div><br>I really like that wording, though I think you =
meant "object" in one place you said "value".=C2=A0 How=
about this sort of wording?<br><br><div style=3D"background-color:rgb(250,=
250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;=
word-wrap:break-word"><code><div><span style=3D"color:#008">template</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#660"><</span><s=
pan style=3D"color:#008">class</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#606">Target</span><span style=3D"color:#660">,</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#008">class</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#606">Source</span><spa=
n style=3D"color:#660">></span><span style=3D"color:#000"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:#606">Target</span><span style=3D"color:#00=
0"> bit_cast</span><span style=3D"color:#660">(</span><span style=3D"color:=
#008">const</span><span style=3D"color:#000"> </span><span style=3D"color:#=
606">Source</span><span style=3D"color:#000"> </span><span style=3D"color:#=
660">&</span><span style=3D"color:#000">src</span><span style=3D"color:=
#660">);</span></div></code></div><br>1. Requires: <span style=3D"font-fami=
ly:courier new,monospace">Target</span> and <span style=3D"font-family:cour=
ier new,monospace">Source</span> shall meet the requirements of <span style=
=3D"font-family:courier new,monospace">TriviallyCopyable</span>, and <span =
style=3D"font-family:courier new,monospace">sizeof(Target)</span> shall equ=
al <span style=3D"font-family:courier new,monospace">sizeof(Source)</span>.=
=C2=A0 [<i>Note: </i>This means that <span style=3D"font-family:courier new=
,monospace">sizeof(Target)</span> and <span style=3D"font-family:courier ne=
w,monospace">sizeof(Source)</span> must be defined; i.e., <span style=3D"fo=
nt-family:courier new,monospace">Target</span> and <span style=3D"font-fami=
ly:courier new,monospace">Source</span> cannot be "array of unknown bo=
und of <span style=3D"font-family:courier new,monospace">T</span>" for=
some type <span style=3D"font-family:courier new,monospace">T</span>. =E2=
=80=94 <i>end note</i>]<br>2. Returns: If the object representation of <spa=
n style=3D"font-family:courier new,monospace">src</span> equals the object =
representation of some value <span style=3D"font-family:courier new,monospa=
ce">t</span> of type Target, then <span style=3D"font-family:courier new,mo=
nospace">t</span>.=C2=A0 Otherwise, the behavior is undefined.=C2=A0 [<i>No=
te: </i>Where defined, this is equivalent to the effect of <span style=3D"f=
ont-family:courier new,monospace">std::memcpy</span>. =E2=80=94 <i>end note=
</i>]<br>3. Complexity: At most <i>O</i>(<i>N</i>), where <i>N</i> has the =
value <span style=3D"font-family:courier new,monospace">sizeof(Target)</spa=
n>.<br>4. Remarks: <span style=3D"font-family:courier new,monospace">Target=
</span> and <span style=3D"font-family:courier new,monospace">Source</span>=
need not have the same alignment requirements.<br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">
<div class=3D"gmail_quote"><span class=3D"">On 12 Oct 2015 21:16, "Myr=
iachan" <<a rel=3D"nofollow">myri...@gmail.com</a>> wrote:<br ty=
pe=3D"attribution"></span><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><=
div dir=3D"ltr">On Friday, October 9, 2015 at 12:47:23 PM UTC-7, Nicol Bola=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><br><div>I'm pretty sur=
e `is_pod` is more strict than is absolutely necessary.<br><br>Trivial copy=
ability is needed for `memcpy` to actually produce defined results. However=
, trivial copyability alone only allows copying between two objects of the =
same type. If you want to memcpy between two objects of different types, th=
en in order to get defined behavior, the types must be layout compatible.<b=
r><br>Of course, the OP clearly does not care about what is and is not well=
-defined. Binary int-to-float conversions do not produce standard-defined b=
ehavior. So if the goal is to make bit_copy<int, float> actually work=
, you don't care about what is technically legal C++.<br><br></div></bl=
ockquote><div><br>What's wrong with defining <span style=3D"font-family=
:courier new,monospace">bit_cast</span>/<span style=3D"font-family:courier =
new,monospace">bit_copy</span> such that the results of such a cast as impl=
ementation-defined, with a non-normative note similar to that of [expr.rein=
terpret.cast]/4: "A pointer can be explicitly converted to any integra=
l type large enough to hold it.=C2=A0 The mapping function is implementatio=
n-defined.=C2=A0 [<i>Note:</i> It is intended to be unsurprising to those w=
ho know the addressing structure of the underlying machine. -- <i>end note<=
/i>]"?=C2=A0 That is, the result of <span style=3D"font-family:courier=
new,monospace">bit_cast</span> would be implementation-defined, but its re=
sult should be unsurprising to those with knowledge of the type of the mach=
ine.=C2=A0 <span style=3D"font-family:courier new,monospace">bit_cast</span=
>ing <span style=3D"font-family:courier new,monospace">std::uint32_t(0x3F80=
0000)</span> to <span style=3D"font-family:courier new,monospace">float</sp=
an> on an x86 implementation and getting <span style=3D"font-family:courier=
new,monospace">1.0f</span> would be such an "unsurprising result"=
; for those knowing that the machine is an x86.<br><br>The Standard can cha=
nge to define whatever the Committee feels necessary.=C2=A0 Saying that som=
ething is undefined behavior as a reason to dismiss a proposal is circular =
logic to me.<br><br>Melissa<br></div></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le 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/3H6-V9_qVmQ/unsubscribe" rel=3D"nofollow=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-prop=
osals/3H6-V9_qVmQ/unsubscribe</a>.<br></span>
To unsubscribe from this group and all its topics, send an email to <a rel=
=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</span></blockquote></div>
</blockquote></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le 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/3H6-V9_qVmQ/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/3H6-V9_qVmQ=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1130d1dcf440c20521fd9666--
.