Topic: endian, Just endian
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Fri, 19 Aug 2016 22:34:47 -0400
Raw View
--Apple-Mail=_35EB4E14-ACD9-4568-8C93-5AEE1C7D67E2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
This:
http://howardhinnant.github.io/endian.html
is headed towards the pre-Issaquah mailing.
I=E2=80=99m providing a preview here for review purposes. Constructive cri=
ticism will be gratefully read, and if acted upon will be acknowledged.
Howard
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/E80B5A8A-BAAE-4B69-8F91-8A1836C7456D%40gmail.com=
..
--Apple-Mail=_35EB4E14-ACD9-4568-8C93-5AEE1C7D67E2
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJXt8HHAAoJEGbcHCxKqhWCcuIQAMPytgeXbXBiugMJeLCgEQTw
UFti00rRi981o29AjNu/+Hur687caVxHT3+vHbKMf9pPI8cclKE+YyaMVt7QsnLr
6aXxup5QQSdC98SyxnvJW8cBQp7geKTFsy5BNVo5DdGnSb/ho6x4pOS/xCUw4yY8
ZEiuaYVSrZwp1TAKbvH1HCic8q0pDZDeeR9Yq4CpacVzDRxRHBCUIl5pjVrFsF32
DxkYsKx63ijRMGGLdVJsqGpKP9sEtgNoAIAwDBndcJ9eeylCdHSjEAGDHneWJNwY
B8AZj1ZgNH1vx0HaWjDTxU5VsSNDwPkWfUtyTMFkrtCKFIBEgJDTGTDMB24B+42d
25FsE4dMTF4hDyTs0u/gBUH/NRQlJp7Dyt8vLlXJ/VB74DMGgCthLhSwBU3ZG5/z
AYJmsv+VYIY9E24oWCE/WUkod7qUVH21cJ+VYstP+CrDrhqhrYwkPHsYnTCye0Gi
durDPg4E3sFLwuMCP2jus/td6+RSsWN/NVMCd5EVZ/f7kT8SxhKvtUW55S618UYQ
w5I1LVgFFkVhAcv+qmDs376xTm1Og07inxydERvB87yM7JHXmQ8EPCWWu3RygxgP
1gV1gCnVM085HtPUulT1ZdI29As7jiS7SC9LxGrgIzYZKWCU/BD8zxJHgp8Up+pj
aNe6TTuTptLmLMUxtYEC
=fGJd
-----END PGP SIGNATURE-----
--Apple-Mail=_35EB4E14-ACD9-4568-8C93-5AEE1C7D67E2--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 19 Aug 2016 20:00:57 -0700
Raw View
On sexta-feira, 19 de agosto de 2016 22:34:47 PDT Howard Hinnant wrote:
> This:
>=20
> http://howardhinnant.github.io/endian.html
>=20
> is headed towards the pre-Issaquah mailing.
>=20
> I=E2=80=99m providing a preview here for review purposes. Constructive c=
riticism
> will be gratefully read, and if acted upon will be acknowledged.
Yes, please. We desperately need that. Since 1998, as you wrote. As it is,=
=20
your proposal is very useful and should be accepted.
The only comment I have is about your explanation, which talks about "most=
=20
significant byte placed first". In fact, this applies also to bits and, thu=
s, to=20
bitfields. Which brings the criticism about macros back into focus. Here's =
an=20
example that I added to Qt in 5.8:
struct ShortData {
#if Q_BYTE_ORDER =3D=3D Q_LITTLE_ENDIAN
quintptr status : 8;
#endif
// note: this is only 24 bits on 32-bit systems...
qintptr msecs : sizeof(void *) * 8 - 8;
#if Q_BYTE_ORDER =3D=3D Q_BIG_ENDIAN
quintptr status : 8;
#endif
};
This is a "Short DateTime Optimisation", which, like your typical SSO,=20
requires setting the LSB to indicate that the pointer it's in a union with =
is=20
otherwise not valid.
Another example of bitfields and endianness macros is the DNS HEADER struct=
ure=20
you can find in <arpa/nameser_compat.h> (see [1] if you don't have it).
Unless we can use C++17's if constexpr in a class definition...
[1] http://www.scs.stanford.edu/histar/src/pkg/uclibc/include/arpa/
nameser_compat.h
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3880079.r23XSYgGCR%40tjmaciei-mobl1.
.
Author: Rene Rivera <grafikrobot@gmail.com>
Date: Fri, 19 Aug 2016 22:01:35 -0500
Raw View
--001a114004b672e293053a7808f2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Aug 19, 2016 at 9:34 PM, Howard Hinnant <howard.hinnant@gmail.com>
wrote:
> This:
>
> http://howardhinnant.github.io/endian.html
>
> is headed towards the pre-Issaquah mailing.
>
> I=E2=80=99m providing a preview here for review purposes. Constructive c=
riticism
> will be gratefully read, and if acted upon will be acknowledged.
>
"A ancient, time-honored" =3D=3D> "An ancient, time-honored"
--=20
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAHEh_Gj2TUeT_epT0udeWZ-9X3PXES3q31b658ceQNWsjhC=
1vA%40mail.gmail.com.
--001a114004b672e293053a7808f2
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 F=
ri, Aug 19, 2016 at 9:34 PM, Howard Hinnant <span dir=3D"ltr"><<a href=
=3D"mailto:howard.hinnant@gmail.com" target=3D"_blank">howard.hinnant@gmail=
..com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">This:<br>
<br>
<a href=3D"http://howardhinnant.github.io/endian.html" rel=3D"noreferrer" t=
arget=3D"_blank">http://howardhinnant.github.io<wbr>/endian.html</a><br>
<br>
is headed towards the pre-Issaquah mailing.<br>
<br>
I=E2=80=99m providing a preview here for review purposes.=C2=A0 Constructiv=
e criticism will be gratefully read, and if acted upon will be acknowledged=
..<br></blockquote><div><br></div><div>"A ancient, time-honored" =
=3D=3D> "An ancient, time-honored"</div></div><br><div><br></d=
iv>-- <br><div data-smartmail=3D"gmail_signature"><div dir=3D"ltr">-- Rene =
Rivera<br>-- Grafik - Don't Assume Anything<br>-- Robot Dreams -=C2=A0<=
a href=3D"http://robot-dreams.net/" target=3D"_blank">http://robot-dreams.n=
et</a><br>-- rrivera/<a href=3D"http://acm.org/" target=3D"_blank">acm.org<=
/a>=C2=A0(msn)=C2=A0-=C2=A0<wbr>grafikrobot/aim,yahoo,skype,<wbr>efnet,gmai=
l</div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHEh_Gj2TUeT_epT0udeWZ-9X3PXES3q31b6=
58ceQNWsjhC1vA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_Gj2TUeT_epT=
0udeWZ-9X3PXES3q31b658ceQNWsjhC1vA%40mail.gmail.com</a>.<br />
--001a114004b672e293053a7808f2--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Fri, 19 Aug 2016 22:24:42 -0500
Raw View
On Fri, Aug 19, 2016 at 9:34 PM, Howard Hinnant
<howard.hinnant@gmail.com> wrote:
>
>
> http://howardhinnant.github.io/endian.html
>
> is headed towards the pre-Issaquah mailing.
>
> I=E2=80=99m providing a preview here for review purposes. Constructive c=
riticism will be gratefully read, and if acted upon will be acknowledged.
20.15.9 Endian -> 20.15.9 Endianness
the endian of the execution environment -> the endianness of the
execution environment
--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAGsORuARLwjbvktTDny9tPcVzoyL_SaMH8%2B0dV4g8Mb0R=
WQL3w%40mail.gmail.com.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 20 Aug 2016 11:32:38 +0200
Raw View
Le 20/08/2016 =C3=A0 04:34, Howard Hinnant a =C3=A9crit :
> This:
>
> http://howardhinnant.github.io/endian.html
>
> is headed towards the pre-Issaquah mailing.
>
> I=E2=80=99m providing a preview here for review purposes. Constructive c=
riticism will be gratefully read, and if acted upon will be acknowledged.
>
> Howard
>
Wondering if the native value shouldn't go out from the enum
enum class endianness
{
little =3D see below,
big =3D see below,
unknown =3D see below
};
constexpr endianness native_endian =3D see below;
Here it is clear that endianness could be endianness::little,=20
endianness::big, or other endianness::unknown value.
I'm not sure of the absolute need for endianness::unknown, but it makes=20
more explicit, that there are other kinds of endian.
An alternative could be to use a namespace endian like Boost.Endian does
namespace endian
{
enum class order ....
constexpr order native =3D see below;
// ...
}
where other endian types and functions could be added later on.
Curiously Boost.Endian defines the same enumerations
namespace endian
{
enum class order
{
native =3D see below,
big =3D see below,
little =3D see below,
};
Vicente
[1] http://www.boost.org/doc/libs/1_61_0/libs/endian/doc/conversion.html
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/70ddaa17-8b40-b729-524e-149e093b98c8%40wanadoo.f=
r.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Sat, 20 Aug 2016 06:55:52 -0300
Raw View
--001a1137a448153c89053a7dd230
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
El 19/8/2016 23:34, "Howard Hinnant" <howard.hinnant@gmail.com> escribi=C3=
=B3:
>
> This:
>
> http://howardhinnant.github.io/endian.html
>
> is headed towards the pre-Issaquah mailing.
>
> I=E2=80=99m providing a preview here for review purposes. Constructive c=
riticism
will be gratefully read, and if acted upon will be acknowledged.
Of course it's something we needed so long ago.
My 2 cents: what about adding another member, "network" or alike, which
will always be equal to big, so people (like me) don't need to go and look
for it (e.g. when writing conversion code). My second comment is that maybe
it's worth mentioning something about how this relates to the work being
done in the networking TS (any relationship at all? Could be used to
implement hton/ntoh functioms family, opens the possibility for new
functioms or interfaces? Just a paragraph).
Very nice work Howard. Hope this gets into the std soon.
Daniel.
>
> Howard
>
> --
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/E80B5A8A-BAAE-=
4B69-8F91-8A1836C7456D%40gmail.com
..
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-3yedYO6Jao5%2Bcg4qOz2BCa8-x%3DBWU9yXSHb2h=
TKUYeoA%40mail.gmail.com.
--001a1137a448153c89053a7dd230
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"></p>
<p dir=3D"ltr">El 19/8/2016 23:34, "Howard Hinnant" <<a href=
=3D"mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>> escri=
bi=C3=B3:<br>
><br>
> This:<br>
><br>
> <a href=3D"http://howardhinnant.github.io/endian.html">http://howardhi=
nnant.github.io/endian.html</a><br>
><br>
> is headed towards the pre-Issaquah mailing.<br>
><br>
> I=E2=80=99m providing a preview here for review purposes.=C2=A0 Constr=
uctive criticism will be gratefully read, and if acted upon will be acknowl=
edged.</p>
<p dir=3D"ltr">Of course it's something we needed so long ago.</p>
<p dir=3D"ltr">My 2 cents: what about adding another member, "network&=
quot; or alike, which will always be equal to big, so people (like me) don&=
#39;t need to go and look for it (e.g. when writing conversion code). My se=
cond comment is that maybe it's worth mentioning something about how th=
is relates to the work being done in the networking TS (any relationship at=
all? Could be used to implement hton/ntoh functioms family, opens the poss=
ibility for new functioms or interfaces? Just a paragraph).</p>
<p dir=3D"ltr">Very nice work Howard. Hope this gets into the std soon.</p>
<p dir=3D"ltr">=C2=A0=C2=A0 Daniel.</p>
<p dir=3D"ltr">><br>
> Howard<br>
><br>
> --<br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/E80B5A8A-BAAE-4B69-8F91-8A1836C7=
456D%40gmail.com">https://groups.google.com/a/isocpp.org/d/msgid/std-propos=
als/E80B5A8A-BAAE-4B69-8F91-8A1836C7456D%40gmail.com</a>.<br></p>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3yedYO6Jao5%2Bcg4qOz2BCa8-x%3D=
BWU9yXSHb2hTKUYeoA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3yedYO=
6Jao5%2Bcg4qOz2BCa8-x%3DBWU9yXSHb2hTKUYeoA%40mail.gmail.com</a>.<br />
--001a1137a448153c89053a7dd230--
.
Author: Bo Persson <bop@gmb.dk>
Date: Sat, 20 Aug 2016 12:21:26 +0200
Raw View
On 2016-08-20 04:34, Howard Hinnant wrote:
> This:
>
> http://howardhinnant.github.io/endian.html
>
> is headed towards the pre-Issaquah mailing.
>
> I=E2=80=99m providing a preview here for review purposes. Constructive c=
riticism will be gratefully read, and if acted upon will be acknowledged.
>
> Howard
>
A great proposal, in all its simplicity.
However, there seems to be a cut and paste problem in the comments of=20
the example
if (endian::native =3D=3D endian::big)
// handle big endian
else if (endian::native =3D=3D endian::little)
// handle big endian
else
// handle little endian
which you might want to fix before publication.
Bo Persson
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/np9av5%24tit%241%40blaine.gmane.org.
.
Author: Patrice Roy <patricer@gmail.com>
Date: Sat, 20 Aug 2016 12:50:45 -0400
Raw View
--94eb2c122e2cc6d5b0053a839d4c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
This proposal's a ray of sunshine :)
2016-08-20 6:21 GMT-04:00 Bo Persson <bop@gmb.dk>:
> On 2016-08-20 04:34, Howard Hinnant wrote:
>
>> This:
>>
>> http://howardhinnant.github.io/endian.html
>>
>> is headed towards the pre-Issaquah mailing.
>>
>> I=E2=80=99m providing a preview here for review purposes. Constructive =
criticism
>> will be gratefully read, and if acted upon will be acknowledged.
>>
>> Howard
>>
>>
> A great proposal, in all its simplicity.
>
> However, there seems to be a cut and paste problem in the comments of the
> example
>
> if (endian::native =3D=3D endian::big)
> // handle big endian
> else if (endian::native =3D=3D endian::little)
> // handle big endian
> else
> // handle little endian
>
> which you might want to fix before publication.
>
>
> Bo Persson
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/np9av5%24tit%241%40blaine.gmane.org.
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKiZDp28VoWHk09T%2ByMvrZLtxKYckESN5F1CHXx%2BQv_=
5nBO7Yw%40mail.gmail.com.
--94eb2c122e2cc6d5b0053a839d4c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This proposal's a ray of sunshine :)<br></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-08-20 6:21 GMT-04:00=
Bo Persson <span dir=3D"ltr"><<a href=3D"mailto:bop@gmb.dk" target=3D"_=
blank">bop@gmb.dk</a>></span>:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">On 2016-08-20 04:34, Howard Hinnant wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
This:<br>
<br>
<a href=3D"http://howardhinnant.github.io/endian.html" rel=3D"noreferrer" t=
arget=3D"_blank">http://howardhinnant.github.io<wbr>/endian.html</a><br>
<br>
is headed towards the pre-Issaquah mailing.<br>
<br>
I=E2=80=99m providing a preview here for review purposes.=C2=A0 Constructiv=
e criticism will be gratefully read, and if acted upon will be acknowledged=
..<br>
<br>
Howard<br>
<br>
</blockquote>
<br></span>
A great proposal, in all its simplicity.<br>
<br>
However, there seems to be a cut and paste problem in the comments of the e=
xample<br>
<br>
if (endian::native =3D=3D endian::big)<br>
=C2=A0 =C2=A0 // handle big endian<br>
else if (endian::native =3D=3D endian::little)<br>
=C2=A0 =C2=A0 // handle big endian<br>
else<br>
=C2=A0 =C2=A0 // handle little endian<br>
<br>
which you might want to fix before publication.<br>
<br>
<br>
=C2=A0 =C2=A0 Bo Persson<span class=3D""><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" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/np9av5%24tit%241%40blaine.gmane.org" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/is<wbr>ocp=
p.org/d/msgid/std-proposals<wbr>/np9av5%24tit%241%40blaine.<wbr>gmane.org</=
a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp28VoWHk09T%2ByMvrZLtxKYckESN5F=
1CHXx%2BQv_5nBO7Yw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp28VoWH=
k09T%2ByMvrZLtxKYckESN5F1CHXx%2BQv_5nBO7Yw%40mail.gmail.com</a>.<br />
--94eb2c122e2cc6d5b0053a839d4c--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Sat, 20 Aug 2016 16:05:08 -0400
Raw View
--Apple-Mail=_24F28B5F-F3DE-4BFD-BB3C-57B0CA786E3C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
On Aug 19, 2016, at 11:00 PM, Thiago Macieira <thiago@macieira.org> wrote:
>=20
> On sexta-feira, 19 de agosto de 2016 22:34:47 PDT Howard Hinnant wrote:
>> This:
>>=20
>> http://howardhinnant.github.io/endian.html
>>=20
>> is headed towards the pre-Issaquah mailing.
>>=20
>> I=E2=80=99m providing a preview here for review purposes. Constructive =
criticism
>> will be gratefully read, and if acted upon will be acknowledged.
>=20
> Yes, please. We desperately need that. Since 1998, as you wrote. As it is=
,
> your proposal is very useful and should be accepted.
>=20
> The only comment I have is about your explanation, which talks about "mos=
t
> significant byte placed first". In fact, this applies also to bits and, t=
hus, to
> bitfields.
Thanks. Bit-endian is out of scope for this proposal. Its tiny scope is a=
big feature.
Howard
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/69388D1A-B03B-414A-BF08-86D333B69194%40gmail.com=
..
--Apple-Mail=_24F28B5F-F3DE-4BFD-BB3C-57B0CA786E3C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJXuLf0AAoJEGbcHCxKqhWC6BsQAILmSRQ4QSf890/KHYmHvqKO
Kx9v6cOhPrWvxcmktNZhN4HYppyVdliv2NO8StM7jymqMcBjY6327a+edxUv7dzQ
bEC2uNkKZjwD5pvtS0DxcO4kJOKsynxH573Qn7dAFV7ut1/60OvKyszVimU25Hi4
q7Ixht7783BH6xj4d1mPbvkN21G4hWyKR/R++zaLdaHWfWdUoB6O8A1mY1d+9q/g
hw4ZKJtEKpOxYRjnZmNV3ZgGABXUQe/DJRFWOtN/6qb6NQWGRRw/FhdNcyM5VCU6
ttIBk0QHiPFBkIOx3i87DeEgBkm8ZBVxMGq5nVN9bZs2u+f0nwtxof0016R7ntEh
urQam4+3cxk2RWLf6XlG3S9RFTil5+Meq3IXvL6/qgr0x2UJfpMBMLjd2bKNRScf
XVc1UbRvHaT1qW18FZRNA+Xx8jNiJqNHsjGS2vthvdDNK5gFlDisnUXnnEO/BKc1
khse9W+g2lmnxdc/edt8Ht7IQq3Ly+Z+J2mNwsr4q64UDufOShSZNVAlh/XkYIyb
nz7NIzNs2DB30HAyxpKd3ctTm90FHmieDZW2RBXuRFbKn+rmiw/jsDnQTcGWyDNs
xKdwlExC9qPqKOiQNDj425o+YIOVeK6LOlKWyGxawao/pkbUhdsIIPf6GIE6ilL5
eEaj7EYk94SCwNhsk/9P
=TcEe
-----END PGP SIGNATURE-----
--Apple-Mail=_24F28B5F-F3DE-4BFD-BB3C-57B0CA786E3C--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Sat, 20 Aug 2016 16:05:29 -0400
Raw View
--Apple-Mail=_6824F88D-77AE-4A37-A92B-F19E6568A2A9
Content-Type: text/plain; charset=UTF-8
On Aug 19, 2016, at 11:01 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
>
> "A ancient, time-honored" ==> "An ancient, time-honored"
Thanks fixed.
Howard
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6BB181EC-2DC7-493E-8D03-950266BD70B7%40gmail.com.
--Apple-Mail=_6824F88D-77AE-4A37-A92B-F19E6568A2A9
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJXuLgJAAoJEGbcHCxKqhWCZNkQAJktPt3Ofg9KkQ++U1t9EcpP
lMzSufApebhp9vg+Skq1AOnxKgKg9I8RxdkzGBrCKEbAhoRV41bR5Z4cz/cgG/X8
kMf1fr1nX6aI956rxOxRehfFd+X94n3Wy+KaSXuBbvqV0KazovKRmZ4RMpZFvSRL
smScq5SS+2uJcYQh+3PqE3IgwhEYol/RjmnBuXZ0nB/uiu3yQaG40S/ExIu9kuK1
HWVolLBHPPWr+wOFmGeNTB6lJ2L7p7ENQaPtCFpbH/G9gBlaTtd5qm9Y4wu2SPBj
Eur2o+40yIC464VaELsPhSaN6ael2qZPFaBxo5GUU38GNukG8ZsbpLSlLBbJ3G6l
3DfGNTjUlceVKNiV7TNGvn4MUq8CStRhW5Qer6dmA/uwIwfAZPH64IFSxfWWl0j+
VeQ4JTL7gGjR37TtYAdyi2TJq/xweL+y1RSAREprX9NIngIQQR/mrtHeSRaJ9rtX
gmZSBn0qVAi6ATofukB7YQ/wT1gK8tuLH8T/hE2cb1w8aRYH/W/01gVHHPufSy3J
SWQn5281QKEREO9O1lCyDGqoiD2uBbFjEdWffMGvfTTJP/J3Dl6u9TjPY6oZn2dr
Hpz9urSgzKsR1pixOBJHPEU0Ki/6TUGnMUxnnlUAnlPJ8UlOGTz0c0oQV3uo7n50
PpVmynPw5IoOEswiYWOE
=Qf4L
-----END PGP SIGNATURE-----
--Apple-Mail=_6824F88D-77AE-4A37-A92B-F19E6568A2A9--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Sat, 20 Aug 2016 16:06:01 -0400
Raw View
--Apple-Mail=_9DB59676-C476-43F5-9420-5D2358E38B18
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On Aug 19, 2016, at 11:24 PM, Zhihao Yuan <zy@miator.net> wrote:
>=20
> On Fri, Aug 19, 2016 at 9:34 PM, Howard Hinnant
> <howard.hinnant@gmail.com> wrote:
>>=20
>>=20
>> http://howardhinnant.github.io/endian.html
>>=20
>> is headed towards the pre-Issaquah mailing.
>>=20
>> I=E2=80=99m providing a preview here for review purposes. Constructive =
criticism will be gratefully read, and if acted upon will be acknowledged.
>=20
> 20.15.9 Endian -> 20.15.9 Endianness
>=20
> the endian of the execution environment -> the endianness of the
> execution environment
Thanks, fixed the latter.
Howard
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/74AB2165-3A2B-49DA-B1AC-A9C3BB852763%40gmail.com=
..
--Apple-Mail=_9DB59676-C476-43F5-9420-5D2358E38B18
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJXuLgpAAoJEGbcHCxKqhWC2aoP/is4/JEcX1AAJD0fIPm6Jiae
SUZjennF6oLa65weT6H3QoIXAweTACTISUguZCjTwn47fJwoxJPb588Jh60jfDn7
JkNvmjYXr26pLCdMntKQFU5pqaMjhekZXFl7tzQ8+NugX4it6hTXKHWhPZcYX05p
UEetOqinNyi6K1V6e2Blomxk20YGVvVtD4vPpOSGYz29/avCBlJPKCkKK2piFDjE
nMNizajxI69cI2oHrinrsboLkXyQZJDgdenIWcTpF5XDygda7Mj8uqGI8r+Ollij
lO1Trn9n1WL8moCJPliieXg8OFSuU+Og8BADjfPldiAvAJnP3f0xHNkFUvYbyip4
3vROJySW9JGW6WEsnOL6WMp+XWRXM++NuPqlv2l3izZryRQWY4217wG/QosnjdrF
IPqGJIbVmD7+IHkYWXoOkxOfotohiGqeoKFz3uPExsgbCidt2fi3P6bZlGNu8n7K
DDWLSQFJuYyUJRWt7XFjV/GWkFuRGxXu1Zmw9HQTkfpWIssqBTHO0NyuwFpGxkw9
+KJ7sr1Dax8UyvJ28HzOOxK8Z8vbX6WV/fsHqOC6gDkO0Qg5ZffICRaJ7tzGPQA+
ENffu5WZdW/DdM8QLwdFVV+P7mE+pt1QgAKGlKYiKnTgoUXQpzakOVTg2F5fX3ND
BEeb/0Zuvkk1cj8u4Bs2
=WBSe
-----END PGP SIGNATURE-----
--Apple-Mail=_9DB59676-C476-43F5-9420-5D2358E38B18--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Sat, 20 Aug 2016 16:08:12 -0400
Raw View
--Apple-Mail=_A1766FC8-1CFB-4445-BDDC-4258569AD03D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
On Aug 20, 2016, at 5:32 AM, Vicente J. Botet Escriba <vicente.botet@wanado=
o.fr> wrote:
>=20
> Le 20/08/2016 =C3=A0 04:34, Howard Hinnant a =C3=A9crit :
>> This:
>>=20
>> http://howardhinnant.github.io/endian.html
>>=20
>> is headed towards the pre-Issaquah mailing.
>>=20
>> I=E2=80=99m providing a preview here for review purposes. Constructive =
criticism will be gratefully read, and if acted upon will be acknowledged.
>>=20
>> Howard
>>=20
> Wondering if the native value shouldn't go out from the enum
>=20
> enum class endianness
> {
> little =3D see below,
> big =3D see below,
> unknown =3D see below
> };
>=20
> constexpr endianness native_endian =3D see below;
>=20
>=20
> Here it is clear that endianness could be endianness::little, endianness:=
:big, or other endianness::unknown value.
>=20
> I'm not sure of the absolute need for endianness::unknown, but it makes m=
ore explicit, that there are other kinds of endian.
>=20
> An alternative could be to use a namespace endian like Boost.Endian does
>=20
> namespace endian
> {
> enum class order ....
>=20
> constexpr order native =3D see below;
>=20
> // ...
> }
>=20
> where other endian types and functions could be added later on.
Thanks, but I am fond of the simplicity of the way I have it.
> Curiously Boost.Endian defines the same enumerations
>=20
> namespace endian
> {
> enum class order
> {
> native =3D see below,
> big =3D see below,
> little =3D see below,
> };
Beman and I have discussed this area before (a couple of years ago). There=
has been beneficial cross pollination.
Howard
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4D61561B-0A75-4230-B882-F1625AD6E7E9%40gmail.com=
..
--Apple-Mail=_A1766FC8-1CFB-4445-BDDC-4258569AD03D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJXuLisAAoJEGbcHCxKqhWCLG0P/iYXp5f0Nm/DUyAMjBICvJLd
CtKzftWbIDpRBtzcTquBlkt+dkTs1NAj2UYkPfzzGB8e9bppsVnB+1flCygkJn7k
p+RTcNwtnbl0scco1Vn0UdZ9K8XhuBrfkPiqCKGNuEbQpHAvRB6FMQG1JkzFv3Vu
5D/WUKU4vtnikXIxkkFmo/juv4IJyB9YRbs92xqA2wepuGjVBDT5gGmvf+A8HNUR
LWaJj788rUIGUeIzGb0C4mZysrXUg8D5urhxjgSY9QWM8utN1uq6XITghHDecgmk
/BSM3sb3LhBzcz91KwMlXnP6J9OKHV8doghqDZZGkm7KghEJdCgyz99QCKsth32M
sXgCfewVbtxS7uCwCCRMNNPRwWPfkNAbOv3gq4yc05VA7EtLGMqZqkGpcHjmDkpg
rV7IpzdV7+pAF+KQ29peGx6uA1bJ38EmNzRYnlLBBri0iQ57KK/OnNC7nFTMhnnZ
WKqSVcg88qv9oFdwdgFh6a2ucQbgNCaOYAu/5aLb8n2vBr/FBsZCkXibohtoaBLB
DNGnY+tmiz3Ph9wbPcMvlZoF9FPhfsa1d6tjeJZXw4CGygmOVPrA8lI68OsH1w52
p62t/1UjojegXD1/hidR577FlAhMzIy9gu/U5ve6edyv1NRGQQYixKdcZa2DJZfZ
fwhkAWDjcTdClghn6w4C
=sJrV
-----END PGP SIGNATURE-----
--Apple-Mail=_A1766FC8-1CFB-4445-BDDC-4258569AD03D--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Sat, 20 Aug 2016 16:10:23 -0400
Raw View
--Apple-Mail=_0719A07B-2469-4FEC-9EBA-80D6B9A3A2CF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
On Aug 20, 2016, at 5:55 AM, dgutson . <danielgutson@gmail.com> wrote:
>=20
> My 2 cents: what about adding another member, "network" or alike, which w=
ill always be equal to big, so people (like me) don't need to go and look f=
or it (e.g. when writing conversion code).
Every single name added comes with cost (more to teach if nothing else). I=
=E2=80=99m aiming for =E2=80=9Cas simple as possible."
> My second comment is that maybe it's worth mentioning something about how=
this relates to the work being done in the networking TS (any relationship=
at all? Could be used to implement hton/ntoh functioms family, opens the p=
ossibility for new functioms or interfaces? Just a paragraph).
I=E2=80=99ve added an example hton/ntoh implementation to the description.
Howard
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20D90CD8-B9A2-4E53-BB83-97072965C083%40gmail.com=
..
--Apple-Mail=_0719A07B-2469-4FEC-9EBA-80D6B9A3A2CF
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJXuLkvAAoJEGbcHCxKqhWCidsP/REZ3a8YgnilCP8B+HXD2mOX
pkwOPZvaCdxqIp3q+JqkW2tXA7hQFQNacYm/aM5GZlabqttsrVDQkTxWOhsX1KSc
Jzol7P66+i9YPtf75uSBvVWaATKHXtI3upxrV+hobt5VAfL9ShHHDbNaz3b5gzTK
zYFxOWbIxl4cXF6g5jqK8u5vKPjJmv4p5IC1dfE4y2sHB7HSXoMufu5IJzT1z00p
IHMFEL07ChIDKPB9UTC4ECBMBeDjnvxsfnVndelVxTjXpOlun2mAgiFJv3xdAzM3
cW0NNaJ66KNpEIaqJVoY1jvXsoRIeT9PTAa8alj+p+M77PPtCK18zcnxcgha6j3+
pClPAzF5Z2m1v9CGgpFYXXp8oZMZ6xPjVgxdAo7xy5lQZPPM5bJNrQ8OZDU65O7+
BDaPALrOKAslzi9IxZPy+zt7GxPL+/+oyVIM867L/XIWkxj4AWpM5Utbi8vhybmR
kGzFEOFVO7f3XHePXCxTusXmxa8w9Y3yLBLE9cTW3uOLUPHnKQJ5ko3t6L/SzU2H
d9FV/nhPr4P8dUIbH7kGrVl/mmL191P06ueZkJsZiphBamUULrOLwHC9N2lEK1KA
nXOt3/6bikmO+tLWw/HIuAS7QH/dxlGSFMOgdSQC0QxJ9Yd2eJTzIzONKAkgsOAj
2Sndew3G0qjQgCn4EZgI
=X+nS
-----END PGP SIGNATURE-----
--Apple-Mail=_0719A07B-2469-4FEC-9EBA-80D6B9A3A2CF--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Sat, 20 Aug 2016 16:10:46 -0400
Raw View
--Apple-Mail=_4B1EB362-29AA-4073-B641-992A9EB155B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
On Aug 20, 2016, at 6:21 AM, Bo Persson <bop@gmb.dk> wrote:
>=20
> On 2016-08-20 04:34, Howard Hinnant wrote:
>> This:
>>=20
>> http://howardhinnant.github.io/endian.html
>>=20
>> is headed towards the pre-Issaquah mailing.
>>=20
>> I=E2=80=99m providing a preview here for review purposes. Constructive =
criticism will be gratefully read, and if acted upon will be acknowledged.
>>=20
>> Howard
>>=20
>=20
> A great proposal, in all its simplicity.
>=20
> However, there seems to be a cut and paste problem in the comments of the=
example
>=20
> if (endian::native =3D=3D endian::big)
> // handle big endian
> else if (endian::native =3D=3D endian::little)
> // handle big endian
> else
> // handle little endian
>=20
> which you might want to fix before publication.
Fixed, thanks.
Howard
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/B0482553-5D89-4A4A-8631-8629EACE01FF%40gmail.com=
..
--Apple-Mail=_4B1EB362-29AA-4073-B641-992A9EB155B8
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJXuLlGAAoJEGbcHCxKqhWCYYUP/34NDXtXLnm4gyC/UvQCnEVt
t3B3Gd292BW3kc8wAvoKS3OIq+xonlI9pvBT21gibvRZjjrz05G1H54oNSykLKTR
DSjnIlfVUaTdxelvIjKkfwOxJXELSqN+BUggMDyt3JMoJX17rYtRqNc2vOvl9t3n
yBrOgEpAaCh35DjEHOtdmVloKa2oLzx5DH6/qsdXKKC9Hr5Yi3RPK1QyfFVWdkoK
5FaxPNJUWrY45WZ2YwsVj2Z2JVUIuoxjFfPy6ebufd71O4R6uCYH/vjnIYiYKPTm
QT09U5XJ2unh05P5V0jOd0tEZ/ofP7qEARL1AdW7giyrVNc9RE911/91XCfmAlbu
ZqB0LhGhMMvKmgymC3OlIvpZaqDRHH6+M9bN0sm67NN6aasIBBtLr126oKMt5Xaq
mIgqCwxl/7UfqoXvmJyeBrvmj5/VuIwIaDr4qQOnASjDYj0djm4UymbQvz0bDWNq
D1rtuTXnRLWF+yywY8e/9hMOq31heGI3BSgLCSaIs3aYzgE6bjxadlVWB7BkovrV
gnEvLK4B+wAxCqcACTMLjqHw7KAclWfgdELpk6XVmhi9QBcv80GSVNfS66btiAB3
MCmnyAPOGSuwUdiEyRfOan2sBjTgC8Wv2pPbwbXAbYX3cBQ3LIFQw8ACxYGRiCer
WPQ7OP8ums8CcqeMhqFi
=lunI
-----END PGP SIGNATURE-----
--Apple-Mail=_4B1EB362-29AA-4073-B641-992A9EB155B8--
.
Author: Greg Marr <gregmmarr@gmail.com>
Date: Sat, 20 Aug 2016 19:32:39 -0700 (PDT)
Raw View
------=_Part_2710_1673440845.1471746760107
Content-Type: multipart/alternative;
boundary="----=_Part_2711_417872029.1471746760107"
------=_Part_2711_417872029.1471746760107
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, August 19, 2016 at 10:34:52 PM UTC-4, Howard Hinnant wrote:
>
> This:=20
>
> http://howardhinnant.github.io/endian.html=20
>
> is headed towards the pre-Issaquah mailing.=20
>
> I=E2=80=99m providing a preview here for review purposes. Constructive c=
riticism=20
> will be gratefully read, and if acted upon will be acknowledged.=20
>
"And they can more easily be built on top of class endian once it exists.=
=20
At a minimum we need class endian ..."
Should these, and a few others like them, be "enum class endian" instead?
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f88e918a-ecad-4bfe-adc6-d2e9c84f6859%40isocpp.or=
g.
------=_Part_2711_417872029.1471746760107
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, August 19, 2016 at 10:34:52 PM UTC-4, Howard Hi=
nnant wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">This:
<br>
<br><a href=3D"http://howardhinnant.github.io/endian.html" target=3D"_blank=
" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/ur=
l?q\x3dhttp%3A%2F%2Fhowardhinnant.github.io%2Fendian.html\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNGSSMh2k_Ck4JoQeT57mqCv1KYVJA';return true;" oncl=
ick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fhowardh=
innant.github.io%2Fendian.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGSSM=
h2k_Ck4JoQeT57mqCv1KYVJA';return true;">http://howardhinnant.github.<wb=
r>io/endian.html</a>
<br>
<br>is headed towards the pre-Issaquah mailing.
<br>
<br>I=E2=80=99m providing a preview here for review purposes. =C2=A0Constru=
ctive criticism will be gratefully read, and if acted upon will be acknowle=
dged.
<br></blockquote><div><br></div><div><span style=3D"color: rgb(0, 0, 0); fo=
nt-family: Times; font-size: medium; text-align: justify;">"And they c=
an more easily be built on top of=C2=A0</span><code style=3D"white-space: p=
re; color: rgb(0, 0, 0); text-align: justify;">class endian</code><span sty=
le=3D"color: rgb(0, 0, 0); font-family: Times; font-size: medium; text-alig=
n: justify;">=C2=A0once it exists. At a minimum we need=C2=A0</span><code s=
tyle=3D"white-space: pre; color: rgb(0, 0, 0); text-align: justify;">class =
endian</code><span style=3D"color: rgb(0, 0, 0); font-family: Times; font-s=
ize: medium; text-align: justify;">=C2=A0..."</span></div><div><span s=
tyle=3D"color: rgb(0, 0, 0); font-family: Times; font-size: medium; text-al=
ign: justify;"><br></span></div><div><span style=3D"font-family: Times; fon=
t-size: medium; text-align: justify;"><font color=3D"#000000">Should these,=
and a few others like them, be "enum class endian" instead?<br><=
/font><br></span></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f88e918a-ecad-4bfe-adc6-d2e9c84f6859%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f88e918a-ecad-4bfe-adc6-d2e9c84f6859=
%40isocpp.org</a>.<br />
------=_Part_2711_417872029.1471746760107--
------=_Part_2710_1673440845.1471746760107--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Sat, 20 Aug 2016 22:38:44 -0400
Raw View
--Apple-Mail=_5310160C-00E8-43EA-A196-1AEA714D34B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
On Aug 20, 2016, at 10:32 PM, Greg Marr <gregmmarr@gmail.com> wrote:
>=20
> On Friday, August 19, 2016 at 10:34:52 PM UTC-4, Howard Hinnant wrote:
> This:
>=20
> http://howardhinnant.github.io/endian.html
>=20
> is headed towards the pre-Issaquah mailing.
>=20
> I=E2=80=99m providing a preview here for review purposes. Constructive c=
riticism will be gratefully read, and if acted upon will be acknowledged.
>=20
> "And they can more easily be built on top of class endian once it exists.=
At a minimum we need class endian ..."
>=20
> Should these, and a few others like them, be "enum class endian" instead?
Seems reasonable, thanks.
Howard
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CCADCEA6-84CB-49CA-9716-DA770D15D670%40gmail.com=
..
--Apple-Mail=_5310160C-00E8-43EA-A196-1AEA714D34B5
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJXuRQ1AAoJEGbcHCxKqhWCOjIP/3JGCXaEcDQjz0hieCKRtNMa
ZAQRRcAfteoUrqUy1obDPJ6cjWPUD+dU1DMwfdeoqVv3GyCmKKqFjjNP58D/iwDw
FKXmeneVgCPgBc9j/WorEHOKs0ZmVkky31F0j/Q60r+qx21OMrnqK8BsG77nUk/f
ib66cwMfPmJx4AiqnonumPsLNvLIqXM/f/2M3YdVzCGRpbAVpAcJq/u4d2dTcTNX
PWWx9KvuPY6OAJqa3yqjUQyEBufSPJoU6/Lq4SjLA8+0AkQumDiWnhaRHkvKIJhb
A92Anjd9e6yY+gurxUjoS6peyeYt03g5Uf8ZWYhDtXLkcMjqLgH67W4IR28gusGs
oojDXo4LsqtESfUu/BgzDGHTZiBeXibWgLeyjUOwKGljhcIPcp5sDeneiKTBTqj0
3H4xOvK7zBy6I/YshMl0zsHtmH3Z5Y/1BbsgSNNxOSuE9Ls0KHYrY0+1uIS+6ECq
H7J838YmMU/tX/ew4x5Ba5eL2ujBL5vIo4ngwzWE85v61TeXFtDxhhAu/qblpKje
WqyVH8FDM+dhdBP6x2nD38EoB165zVBvhczavRaA3I1soK6rvkIBySs/8Ii2H1MC
Ed3BX9wJWbRmd8yLIN8aFK5+gQym1pGfgyUBEkkJO7m93SENwYIiYWr4Di5sj11j
U71gk9NyqaJJt95vshDb
=CQYf
-----END PGP SIGNATURE-----
--Apple-Mail=_5310160C-00E8-43EA-A196-1AEA714D34B5--
.
Author: Bjorn Reese <breese@mail1.stofanet.dk>
Date: Sun, 21 Aug 2016 12:50:52 +0200
Raw View
[ Quoting from the proposal ]
> An ancient, time-honored tradition among C++ programmers is detecting
> the endian of their execution environment:
>
> Detecting endianness programmatically in a C++ program
Better references may be:
https://en.wikipedia.org/wiki/Endianness
https://sourceforge.net/p/predef/wiki/Endianness/
Furthermore, endianness (byte order) is also used in Networking TS N4588
(for instance [internet.address.v4.members].)
> Objection #3: I am quite sure that PDP endian is on the way back in.
> PDP is neither big nor little endian. This proposal doesn't handle
> that!
>
> This proposal handles "mixed endian" today by ensuring that
> endian::native equals neither endian::big nor endian::little.
PDP endian is more commonly referred to as "middle endian".
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/958027f6-eb61-4273-d40f-022d9ea1d271%40mail1.stofanet.dk.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 21 Aug 2016 13:29:01 -0700 (PDT)
Raw View
------=_Part_3586_1574649122.1471811342193
Content-Type: multipart/alternative;
boundary="----=_Part_3587_966159269.1471811342193"
------=_Part_3587_966159269.1471811342193
Content-Type: text/plain; charset=UTF-8
The functionality is interesting, but I think it is a bit under-specified.
For example, I would change this sentence:
This subclause describes the endianness of the execution environment.
>
to:
This subclause describes the byte ordering of all scalar types within the
> execution environment.
>
This makes it fully clear that the endian ordering applies to every scalar
type, rather than focusing on the "execution environment". Similarly,
statements of the form "the execution environment is big-endian" might be
better as "scalar types are stored in big-endian ordering".
Furthermore, I think an example or two of the guarantees that you get would
be good. Something like:
uint32_t val = 0x12345678;
unsigned char arr[sizeof(uint32_t)];
memcpy(arr, val, sizeof(uint32_t));
if constexpr (endian::native == endian::little)
assert(arr[0] == 0x78);
else if constexpr (endian::native == endian::big)
assert(arr[0] == 0x12);
Also, I think it would be a good idea for `endian` to use `unsigned int` as
its underlying type rather than `int`. But that may just be personal
preference.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/91ac7248-cea6-4a0c-a5bb-cb6df7da27bb%40isocpp.org.
------=_Part_3587_966159269.1471811342193
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The functionality is interesting, but I think it is a bit =
under-specified.<br><br>For example, I would change this sentence:<br><br><=
blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(2=
04, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">This subclause des=
cribes the endianness of the execution
environment.<br></blockquote><br>to:<br><br><blockquote style=3D"margin: 0p=
x 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1=
ex;" class=3D"gmail_quote">This subclause describes the byte ordering of al=
l scalar types within the execution
environment.<br></blockquote><br>This makes it fully clear that the endian =
ordering applies to every scalar type, rather than focusing on the "ex=
ecution environment". Similarly, statements of the form "the exec=
ution environment is big-endian" might be better as "scalar types=
are stored in big-endian ordering".<br><br>Furthermore, I think an ex=
ample or two of the guarantees that you get would be good. Something like:<=
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"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">uint3=
2_t val </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">0x12345678</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">unsigned</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">char</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> arr</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">[</span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">sizeof</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">u=
int32_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)];=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>memcpy=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">arr</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> val</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">sizeof</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">uint32_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>));</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">constexpr</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">endian</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">native</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
endian</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">little</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">assert</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">arr</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">]</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0x78</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">else</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">if</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">constexpr</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: #000;" class=3D"styled-by-prettify">end=
ian</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">native</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> endian</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">big</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">assert</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">arr</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">[</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">]</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;"=
class=3D"styled-by-prettify">0x12</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span></div></code></div><br>Also, I think it would be=
a good idea for `endian` to use `unsigned int` as its underlying type rath=
er than `int`. But that may just be personal preference.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/91ac7248-cea6-4a0c-a5bb-cb6df7da27bb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/91ac7248-cea6-4a0c-a5bb-cb6df7da27bb=
%40isocpp.org</a>.<br />
------=_Part_3587_966159269.1471811342193--
------=_Part_3586_1574649122.1471811342193--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Sun, 21 Aug 2016 17:23:11 -0400
Raw View
--Apple-Mail=_9FFC6AEB-8B7B-4FFF-9D62-204B70D3E604
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
On Aug 21, 2016, at 4:29 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>=20
> The functionality is interesting, but I think it is a bit under-specified=
..
>=20
> For example, I would change this sentence:
>=20
> This subclause describes the endianness of the execution environment.
>=20
> to:
>=20
> This subclause describes the byte ordering of all scalar types within the=
execution environment.
>=20
> This makes it fully clear that the endian ordering applies to every scala=
r type, rather than focusing on the "execution environment". Similarly, sta=
tements of the form "the execution environment is big-endian" might be bett=
er as "scalar types are stored in big-endian ordering=E2=80=9D.
I=E2=80=99m not touching the encoding of member pointers with a ten foot po=
le. ;-)
I thought about pointers and arithmetic types, but decided against it. If =
the EWG wants to define endian, more power to them. In the meantime these =
words were borrowed and embellished from the POSIX spec, which is good enou=
gh for now. As always, the committee will massage these words as they may.
>=20
> Furthermore, I think an example or two of the guarantees that you get wou=
ld be good. Something like:
>=20
> uint32_t val =3D 0x12345678;
> unsigned char arr[sizeof(uint32_t)];
> memcpy(arr, val, sizeof(uint32_t));
> if constexpr (endian::native =3D=3D endian::little)
> assert(arr[0] =3D=3D 0x78);
> else if constexpr (endian::native =3D=3D endian::big)
> assert(arr[0] =3D=3D 0x12);
The more said here, the more opportunity for error.
>=20
> Also, I think it would be a good idea for `endian` to use `unsigned int` =
as its underlying type rather than `int`. But that may just be personal pre=
ference.
I=E2=80=99m not against this but haven=E2=80=99t come up with any rationale=
to favor any underlying type.
Howard
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/FFEBB9C4-6D13-4125-9A73-EA4C648A2634%40gmail.com=
..
--Apple-Mail=_9FFC6AEB-8B7B-4FFF-9D62-204B70D3E604
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJXuhu/AAoJEGbcHCxKqhWCEYIP/0w4GaJgmXrDFMqsVXuQAdHo
FecURbSqEjuv86LiWtlD/WJcDzofkGAPXI74ID7NvwXIHbLEsaQ1PhVbLa13s8Gg
RL3bjnVDrd3gB42VLzIRZ0XZdwbFCDfhlfKYFbioibNdUKeNhLlA6j4ql/T8E2vw
V2cjkColzw/3FlNLP6GRnZMA1VkdkFN4oFiP8I2uk5QA2TOa7gGkTwzQsFEqMTtg
UuMsLPdDpi+iRWW7Pk94FB0zQ4drY6P6oYRmqkrmqbbamlzcntymqbIl2eIbDtPF
FgVWS6UD4tYspWgEnSAhCI3+158xNM3re5IQMZ8jKS0yAgVhGMnTwwTk9oVmp4Lj
hvGY25ExwDobR+W2pXXH4/omuK6N5VTsJaMpFrOnPn+tRompfArGSkQLkb4OJIYZ
aFQjyxQE52nJ/BMrYVmj/k0Rio1bxmHxkS+e+34aqZfFiU4VDd+OZnwaX7j+tl48
7vV/AD4ni8x/1TSyq5lyCn4xokEzagdpIYotDC90JDz36H1xw9h+G5MyFeslhqc2
W3fFij7lb7yrBH8YjRLeKg65Zne+zid2FnWiChyQWDQAFmT5XIaD0ibCKXgsIMqn
olr3lRkB0jOO76KLE/D5YJfeELWJkhET39IpMN3cFQqNDSI6XXML69EeY9vPGp2L
hrKb/BEHqJXHIN+u89Lt
=oOrH
-----END PGP SIGNATURE-----
--Apple-Mail=_9FFC6AEB-8B7B-4FFF-9D62-204B70D3E604--
.
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 30 Aug 2016 00:56:20 -0700 (PDT)
Raw View
------=_Part_7874_687984895.1472543781213
Content-Type: multipart/alternative;
boundary="----=_Part_7875_1602767091.1472543781214"
------=_Part_7875_1602767091.1472543781214
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, August 19, 2016 at 7:34:52 PM UTC-7, Howard Hinnant wrote:
>
> http://howardhinnant.github.io/endian.html=20
>
> is headed towards the pre-Issaquah mailing.=20
>
> I=E2=80=99m providing a preview here for review purposes. Constructive c=
riticism=20
> will be gratefully read, and if acted upon will be acknowledged.=20
>
>
What about a system for which sizeof(long long) =3D=3D 1? In other words, =
a=20
system in which all standard types are the same size, with an address space=
=20
addressable in words instead of what we'd more typically call "bytes"? Not=
=20
that I know of such a system.
In such a system, there is no such thing as endianness (as in byte order). =
=20
I guess that it would be handled similarly to PDP endianness?
Finally, I've heard that some systems have unusual forms of endianness for=
=20
floating-point numbers but not for integers, or possibly having opposite=20
endianness. (Wikipedia lists older ARM systems' doubles--perhaps before=20
hardware floating-point in ARM?) How would those systems be handled?
On Friday, August 19, 2016 at 8:01:01 PM UTC-7, Thiago Macieira wrote:
> The only comment I have is about your explanation, which talks about "mos=
t=20
> significant byte placed first". In fact, this applies also to bits and,=
=20
> thus, to=20
> bitfields. Which brings the criticism about macros back into focus. Here'=
s=20
> an=20
> example that I added to Qt in 5.8:=20
>
>
As far as I know, there is also no requirement that endianness of the=20
system control the order of bits in bitfields...? In practice, that is the=
=20
case, though.
Melissa
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2d31b898-9277-496d-97da-fcb19645b221%40isocpp.or=
g.
------=_Part_7875_1602767091.1472543781214
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, August 19, 2016 at 7:34:52 PM UTC-7, Howard Hin=
nant wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><a href=3D"http://h=
owardhinnant.github.io/endian.html" target=3D"_blank" rel=3D"nofollow" onmo=
usedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fhow=
ardhinnant.github.io%2Fendian.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCN=
GSSMh2k_Ck4JoQeT57mqCv1KYVJA';return true;" onclick=3D"this.href=3D'=
;http://www.google.com/url?q\x3dhttp%3A%2F%2Fhowardhinnant.github.io%2Fendi=
an.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGSSMh2k_Ck4JoQeT57mqCv1KYVJ=
A';return true;">http://howardhinnant.github.<wbr>io/endian.html</a>
<br>
<br>is headed towards the pre-Issaquah mailing.
<br>
<br>I=E2=80=99m providing a preview here for review purposes. =C2=A0Constru=
ctive criticism will be gratefully read, and if acted upon will be acknowle=
dged.
<br>
<br></blockquote><div><br>What about a system for which sizeof(long long) =
=3D=3D 1?=C2=A0 In other words, a system in which all standard types are th=
e same size, with an address space addressable in words instead of what we&=
#39;d more typically call "bytes"?=C2=A0 Not that I know of such =
a system.<br><br>In such a system, there is no such thing as endianness (as=
in byte order).=C2=A0 I guess that it would be handled similarly to PDP en=
dianness?<br><br>Finally, I've heard that some systems have unusual for=
ms of endianness for floating-point numbers but not for integers, or possib=
ly having opposite endianness.=C2=A0 (Wikipedia lists older ARM systems'=
; doubles--perhaps before hardware floating-point in ARM?)=C2=A0 How would =
those systems be handled?<br><br><br>On Friday, August 19, 2016 at 8:01:01 =
PM UTC-7, Thiago Macieira wrote:<br><blockquote style=3D"margin: 0px 0px 0p=
x 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" cla=
ss=3D"gmail_quote">The only comment I have is about your explanation, which=
talks about "most=20
<br>significant byte placed first". In fact, this applies also to bits=
and, thus, to=20
<br>bitfields. Which brings the criticism about macros back into focus. Her=
e's an=20
<br>example that I added to Qt in 5.8:
<br>
<br></blockquote><br>As far as I know, there is also no requirement that en=
dianness of the system control the order of bits in bitfields...?=C2=A0 In =
practice, that is the case, though.<br><br>Melissa<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2d31b898-9277-496d-97da-fcb19645b221%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2d31b898-9277-496d-97da-fcb19645b221=
%40isocpp.org</a>.<br />
------=_Part_7875_1602767091.1472543781214--
------=_Part_7874_687984895.1472543781213--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Tue, 30 Aug 2016 11:23:05 +0200
Raw View
--001a1142500e406b72053b4687ca
Content-Type: text/plain; charset=UTF-8
On Tue, Aug 30, 2016 at 9:56 AM, Myriachan <myriachan@gmail.com> wrote:
> Finally, I've heard that some systems have unusual forms of endianness
for floating-point numbers but not for integers, or possibly having
opposite endianness. (Wikipedia lists older ARM systems' doubles--perhaps
before hardware floating-point in ARM?) How would those systems be handled?
Good point. Is there anything in the C++ standard that would require that
even different integral types have the same endianness? If not, then the
class should be a template like numeric_limits. And perhaps this could just
be an extension of numeric_limits then.
Cheers,
V.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3rhV7E%3DZFFofJRhKkus%2BZ2njKGc5RUa1rc3TbK18ukXA%40mail.gmail.com.
--001a1142500e406b72053b4687ca
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 T=
ue, Aug 30, 2016 at 9:56 AM, Myriachan <span dir=3D"ltr"><<a href=3D"mai=
lto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>></spa=
n> wrote:<br><div><br></div><div>> Finally, I've heard that some sys=
tems have unusual forms of endianness for floating-point numbers but not fo=
r integers, or possibly having opposite endianness.=C2=A0 (Wikipedia lists =
older ARM systems' doubles--perhaps before hardware floating-point in A=
RM?)=C2=A0 How would those systems be handled?</div><div><br></div><div>Goo=
d point. Is there anything in the C++ standard that would require that even=
different integral types have the same endianness? If not, then the class =
should be a template like numeric_limits. And perhaps this could just be an=
extension of numeric_limits then.</div><div><br></div><div>Cheers,</div><d=
iv>V.</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3rhV7E%3DZFFofJRhKkus%2BZ2njKG=
c5RUa1rc3TbK18ukXA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3rhV7E=
%3DZFFofJRhKkus%2BZ2njKGc5RUa1rc3TbK18ukXA%40mail.gmail.com</a>.<br />
--001a1142500e406b72053b4687ca--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Tue, 30 Aug 2016 12:46:38 +0300
Raw View
This is a multi-part message in MIME format.
--------------3EEEC9D9C2BFE0B3585BC7EE
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
On 08/30/2016 10:56 AM, Myriachan wrote:
> On Friday, August 19, 2016 at 7:34:52 PM UTC-7, Howard Hinnant wrote:
>
> http://howardhinnant.github.io/endian.html
> <http://howardhinnant.github.io/endian.html>
>
> is headed towards the pre-Issaquah mailing.
>
> I=E2=80=99m providing a preview here for review purposes. Constructi=
ve
> criticism will be gratefully read, and if acted upon will be
> acknowledged.
>
>
> What about a system for which sizeof(long long) =3D=3D 1? In other words=
,=20
> a system in which all standard types are the same size, with an=20
> address space addressable in words instead of what we'd more typically=20
> call "bytes"? Not that I know of such a system.
>
> In such a system, there is no such thing as endianness (as in byte=20
> order). I guess that it would be handled similarly to PDP endianness?
>
> Finally, I've heard that some systems have unusual forms of endianness=20
> for floating-point numbers but not for integers, or possibly having=20
> opposite endianness. (Wikipedia lists older ARM systems'=20
> doubles--perhaps before hardware floating-point in ARM?) How would=20
> those systems be handled?
>
>
Perhaps the standard should specify overloads for
void to_big_endian(const T&, char*);
T from_big_endian(const char*, void_t<T>);
void to_little_endian(const T&, char*);
T from_big_endian(const char*, void_t<T>);
for all the arithmetic types (except bool).
> On Friday, August 19, 2016 at 8:01:01 PM UTC-7, Thiago Macieira wrote:
>
> The only comment I have is about your explanation, which talks
> about "most
> significant byte placed first". In fact, this applies also to bits
> and, thus, to
> bitfields. Which brings the criticism about macros back into
> focus. Here's an
> example that I added to Qt in 5.8:
>
>
> As far as I know, there is also no requirement that endianness of the=20
> system control the order of bits in bitfields...? In practice, that=20
> is the case, though.
>
> Melissa
> --=20
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2d31b898-927=
7-496d-97da-fcb19645b221%40isocpp.org=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2d31b898-92=
77-496d-97da-fcb19645b221%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5fd2d9f4-489b-1e91-9a3b-2b7cce07941c%40scylladb.=
com.
--------------3EEEC9D9C2BFE0B3585BC7EE
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<p><br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 08/30/2016 10:56 AM, Myriachan
wrote:<br>
</div>
<blockquote
cite=3D"mid:2d31b898-9277-496d-97da-fcb19645b221@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">On Friday, August 19, 2016 at 7:34:52 PM UTC-7,
Howard Hinnant wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><a
moz-do-not-send=3D"true"
href=3D"http://howardhinnant.github.io/endian.html"
target=3D"_blank" rel=3D"nofollow"
onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fhow=
ardhinnant.github.io%2Fendian.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCN=
GSSMh2k_Ck4JoQeT57mqCv1KYVJA';return
true;"
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fhowardh=
innant.github.io%2Fendian.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGSSM=
h2k_Ck4JoQeT57mqCv1KYVJA';return
true;">http://howardhinnant.github.<wbr>io/endian.html</a>
<br>
<br>
is headed towards the pre-Issaquah mailing.
<br>
<br>
I=E2=80=99m providing a preview here for review purposes.
=C2=A0Constructive criticism will be gratefully read, and if acte=
d
upon will be acknowledged.
<br>
<br>
</blockquote>
<div><br>
What about a system for which sizeof(long long) =3D=3D 1?=C2=A0 I=
n
other words, a system in which all standard types are the same
size, with an address space addressable in words instead of
what we'd more typically call "bytes"?=C2=A0 Not that I know of
such a system.<br>
<br>
In such a system, there is no such thing as endianness (as in
byte order).=C2=A0 I guess that it would be handled similarly to
PDP endianness?<br>
<br>
Finally, I've heard that some systems have unusual forms of
endianness for floating-point numbers but not for integers, or
possibly having opposite endianness.=C2=A0 (Wikipedia lists older
ARM systems' doubles--perhaps before hardware floating-point
in ARM?)=C2=A0 How would those systems be handled?<br>
<br>
<br>
</div>
</div>
</blockquote>
<br>
Perhaps the standard should specify overloads for<br>
<br>
=C2=A0 void to_big_endian(const T&, char*);<br>
=C2=A0 T from_big_endian(const char*, void_t<T>);<br>
=C2=A0 void to_little_endian(const T&, char*);<br>
=C2=A0 T from_big_endian(const char*, void_t<T>);<br>
<br>
for all the arithmetic types (except bool).<br>
<br>
<blockquote
cite=3D"mid:2d31b898-9277-496d-97da-fcb19645b221@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>On Friday, August 19, 2016 at 8:01:01 PM UTC-7, Thiago
Macieira wrote:<br>
<blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px
solid rgb(204, 204, 204); padding-left: 1ex;"
class=3D"gmail_quote">The only comment I have is about your
explanation, which talks about "most <br>
significant byte placed first". In fact, this applies also
to bits and, thus, to <br>
bitfields. Which brings the criticism about macros back into
focus. Here's an <br>
example that I added to Qt in 5.8:
<br>
<br>
</blockquote>
<br>
As far as I know, there is also no requirement that endianness
of the system control the order of bits in bitfields...?=C2=A0 In
practice, that is the case, though.<br>
<br>
Melissa<br>
</div>
</div>
-- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
To view this discussion on the web visit <a
moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2d31b8=
98-9277-496d-97da-fcb19645b221%40isocpp.org?utm_medium=3Demail&utm_sour=
ce=3Dfooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2=
d31b898-9277-496d-97da-fcb19645b221%40isocpp.org</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5fd2d9f4-489b-1e91-9a3b-2b7cce07941c%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/5fd2d9f4-489b-1e91-9a3b-2b7cce0794=
1c%40scylladb.com</a>.<br />
--------------3EEEC9D9C2BFE0B3585BC7EE--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Tue, 30 Aug 2016 10:39:04 -0400
Raw View
--Apple-Mail=_5279FFAA-03B6-4C3C-9EBB-8A80D877D8B9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
On Aug 30, 2016, at 3:56 AM, Myriachan <myriachan@gmail.com> wrote:
>=20
> On Friday, August 19, 2016 at 7:34:52 PM UTC-7, Howard Hinnant wrote:
>> http://howardhinnant.github.io/endian.html
>>=20
>> is headed towards the pre-Issaquah mailing.
>>=20
>> I=E2=80=99m providing a preview here for review purposes. Constructive =
criticism will be gratefully read, and if acted upon will be acknowledged.
>>=20
>=20
> What about a system for which sizeof(long long) =3D=3D 1? In other words=
, a system in which all standard types are the same size, with an address s=
pace addressable in words instead of what we'd more typically call "bytes"?=
Not that I know of such a system.
About 16 years ago I worked on a DSP where this was true. Everything was 2=
4 bits: from char to long long to double. In practice it won=E2=80=99t mat=
ter how native is set on that platform because in typical use (as shown in =
the example hton implementation, code needs to check for sizeof =3D=3D 1 (w=
hich is true for all types on the system you describe). I.e. on such a sys=
tem, even though the hton code says you=E2=80=99re checking endian::native,=
you=E2=80=99re always short-circuiting the logic before you get to that ch=
eck because sizeof(Integral) =3D=3D 1.
>=20
> In such a system, there is no such thing as endianness (as in byte order)=
.. I guess that it would be handled similarly to PDP endianness?
Exactly.
>=20
> Finally, I've heard that some systems have unusual forms of endianness fo=
r floating-point numbers but not for integers, or possibly having opposite =
endianness. (Wikipedia lists older ARM systems' doubles--perhaps before ha=
rdware floating-point in ARM?) How would those systems be handled?
One of the tried-and-true techniques of standardization is to:
Standardize existing practice.
__ORDER_LITTLE_ENDIAN__, __ORDER_BIG_ENDIAN__ and __BYTE_ORDER__ are existi=
ng practice with at least two major compilers (probably more but I don=E2=
=80=99t have them available to check). This proposal simply packages this =
existing practice using modern C++ tools.
Howard
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/EE77257F-AFCE-44EC-8DF0-7832F0B4D206%40gmail.com=
..
--Apple-Mail=_5279FFAA-03B6-4C3C-9EBB-8A80D877D8B9
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJXxZqJAAoJEGbcHCxKqhWCnNQP/iem6TXd82ZdZx9GiXHEhMkT
Mkweo5aA6nY6L9BclGqowQHa2PHIMoq7Z5QAb1Tt7zjBUQx9l5mrQWD4Uwzck7Sx
wpOYOZ8uEeZ27yPBigBqcL7mp9pnUQ+Icjahoed1qXRefwE3LUkBCR3XxuMS+1Dz
/sRRisf2vWLnyUlLBEtNIG9/RO0eRrx6u19ZnJceNAH99o2QEQ5UU2ZphQryth/G
SuMzQ0ZgJIGX9T4tNXicP3UTGrm0lKVisuHxiL4QYyMqQYgxCo4dF1IVjTVkp4gx
utuQwMGzGDAQgqhRsYvDsiBjqtqFQEqiMDcCyl9AXArToGsmsuoKw8NCU/xg5L6c
Tgud0ARSAYvOl9ZF7nUf8OWMT4oEQtC4uKtyiTedrX17Hu5ao6RB+oy8zA4ZI+zO
fMSxyKxEEmtSyeLbJg5Vvlz2MCG5z6wR9S6q0RJcw46nZIurCO4CJKq0V9JbzI5m
tF5lzn4lPmeRSyjUmG4Xr1ViXttShqx6Qp1TBVW50QvU/jh3HNkMCz5JJd0WL2rC
Z9OnJHLUb2OhJiSPfluw34x46+lHfkkjx6lTsuIIp2yy9/i9Orj5+YfGdp95ouCV
R6pwuCV+SCG4gY3y3ZU29fQuGxoorjjpus6MLfRumzUOd6NgyBoJbhPu9Z7ivyrw
LXPoWP4B7WIZt1Y4EWcQ
=Ba14
-----END PGP SIGNATURE-----
--Apple-Mail=_5279FFAA-03B6-4C3C-9EBB-8A80D877D8B9--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 30 Aug 2016 11:21:53 -0700 (PDT)
Raw View
------=_Part_5417_683853656.1472581314141
Content-Type: multipart/alternative;
boundary="----=_Part_5418_974088627.1472581314141"
------=_Part_5418_974088627.1472581314141
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, August 30, 2016 at 10:39:10 AM UTC-4, Howard Hinnant wrote:
>
> On Aug 30, 2016, at 3:56 AM, Myriachan <myri...@gmail.com <javascript:>>=
=20
> wrote:=20
> >=20
> >=20
> >=20
> > Finally, I've heard that some systems have unusual forms of endianness=
=20
> for floating-point numbers but not for integers, or possibly having=20
> opposite endianness. (Wikipedia lists older ARM systems' doubles--perhap=
s=20
> before hardware floating-point in ARM?) How would those systems be=20
> handled?=20
>
> One of the tried-and-true techniques of standardization is to:=20
>
> Standardize existing practice.=20
>
> __ORDER_LITTLE_ENDIAN__, __ORDER_BIG_ENDIAN__ and __BYTE_ORDER__ are=20
> existing practice with at least two major compilers (probably more but I=
=20
> don=E2=80=99t have them available to check). This proposal simply packag=
es this=20
> existing practice using modern C++ tools.
>
What good is standardizing existing practice if you can't actually say what=
=20
that existing practice *means*? That's the part that doesn't make sense=20
here.
The standard specifies behavior. Unless these values are tied into=20
genuinely observable behavior, then standardizing them doesn't really=20
accomplish anything. And if they are tied into genuinely observable=20
behavior, then we need to know what that behavior is.
I don't understand the point of standardizing three numbers without giving=
=20
any meaning to these numbers.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2b8696f8-2287-4c66-b74e-f033d1901bed%40isocpp.or=
g.
------=_Part_5418_974088627.1472581314141
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, August 30, 2016 at 10:39:10 AM UTC-4, Howard H=
innant wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Aug 30, 2016, =
at 3:56 AM, Myriachan <<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"TOW4Z4gYEgAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascri=
pt:';return true;">myri...@gmail.com</a>> wrote:
<br>>=20
<br>>
<br>>=20
<br>> Finally, I've heard that some systems have unusual forms of en=
dianness for floating-point numbers but not for integers, or possibly havin=
g opposite endianness. =C2=A0(Wikipedia lists older ARM systems' double=
s--perhaps before hardware floating-point in ARM?) =C2=A0How would those sy=
stems be handled?
<br>
<br>One of the tried-and-true techniques of standardization is to:
<br>
<br>=C2=A0 =C2=A0Standardize existing practice.
<br>
<br>__ORDER_LITTLE_ENDIAN__, __ORDER_BIG_ENDIAN__ and __BYTE_ORDER__ are ex=
isting practice with at least two major compilers (probably more but I don=
=E2=80=99t have them available to check). =C2=A0This proposal simply packag=
es this existing practice using modern C++ tools.<br></blockquote><div><br>=
What good is standardizing existing practice if you can't actually say =
what that existing practice <i>means</i>? That's the part that doesn=
9;t make sense here.<br><br>The standard specifies behavior. Unless these v=
alues are tied into genuinely observable behavior, then standardizing them =
doesn't really accomplish anything. And if they are tied into genuinely=
observable behavior, then we need to know what that behavior is.<br><br>I =
don't understand the point of standardizing three numbers without givin=
g any meaning to these numbers.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2b8696f8-2287-4c66-b74e-f033d1901bed%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2b8696f8-2287-4c66-b74e-f033d1901bed=
%40isocpp.org</a>.<br />
------=_Part_5418_974088627.1472581314141--
------=_Part_5417_683853656.1472581314141--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Tue, 30 Aug 2016 14:40:03 -0400
Raw View
--Apple-Mail=_F61FEB8A-306A-4AFF-971B-DA0C6C8EB88F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
On Aug 30, 2016, at 2:21 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>=20
> On Tuesday, August 30, 2016 at 10:39:10 AM UTC-4, Howard Hinnant wrote:
>> On Aug 30, 2016, at 3:56 AM, Myriachan <myri...@gmail.com> wrote:
>>> >
>>> >
>>> >
>>> > Finally, I've heard that some systems have unusual forms of endiannes=
s for floating-point numbers but not for integers, or possibly having oppos=
ite endianness. (Wikipedia lists older ARM systems' doubles--perhaps befor=
e hardware floating-point in ARM?) How would those systems be handled?
>>>=20
>> One of the tried-and-true techniques of standardization is to:
>>=20
>> Standardize existing practice.
>>=20
>> __ORDER_LITTLE_ENDIAN__, __ORDER_BIG_ENDIAN__ and __BYTE_ORDER__ are exi=
sting practice with at least two major compilers (probably more but I don=
=E2=80=99t have them available to check). This proposal simply packages th=
is existing practice using modern C++ tools.
>>=20
> What good is standardizing existing practice if you can't actually say wh=
at that existing practice means? That's the part that doesn't make sense he=
re.
>=20
> The standard specifies behavior. Unless these values are tied into genuin=
ely observable behavior, then standardizing them doesn't really accomplish =
anything. And if they are tied into genuinely observable behavior, then we =
need to know what that behavior is.
>=20
> I don't understand the point of standardizing three numbers without givin=
g any meaning to these numbers.
I have no doubt that the LWG (or LEWG) will offer improvements to the wordi=
ng. But note that we have been living with the concept of endian in the C+=
+ standard for half a decade and the sky hasn=E2=80=99t fallen (yet). See =
[locale.stdcvt] for our current use of the terms little endian and big endi=
an.
The proposal=E2=80=99s current description of endian is borrowed from what =
the POSIX standard says about it (http://pubs.opengroup.org/onlinepubs/9699=
919799/basedefs/V1_chap03.html), which seems like a pretty good straw man t=
o get the process started. To the best of my knowledge, no one has complai=
ned that the POSIX description of endian is meaningless.
I=E2=80=99ve also scanned the LWG issues list for issues in [locale.stdcvt]=
.. There are two:
http://cplusplus.github.io/LWG/lwg-active.html#2507
http://cplusplus.github.io/LWG/lwg-defects.html#2229
Neither is concerned with this section=E2=80=99s use of the word =E2=80=9Ce=
ndian=E2=80=9D. Though if you feel that this is an issue that needs to be =
addressed in the current standard, here are instructions on how to get that=
process started:
http://cplusplus.github.io/LWG/lwg-active.html#submit_issue
Howard
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/81EB79E5-32A0-4DB9-9491-5C9C3DC818EB%40gmail.com=
..
--Apple-Mail=_F61FEB8A-306A-4AFF-971B-DA0C6C8EB88F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJXxdMIAAoJEGbcHCxKqhWCmcwP/0Py9ZSwhiF1V6Rm7CqjBhIL
IyoQhpnnHBx22ycSzGkYPirohv9dJU0wlOWtBq0Hmfq7UjkXAMN6yRAlknfUvl/9
YKUI92BpYYXo9ao4/REqUDhTaKkj/v9sIExs4My5aluqDSwfiFfGUZ/KzDR0A7RV
EAVRJuzhPzx1h4cs+Iz03KjI6vsDgokB3XqqET9x98NbPAWdf1KmFHp4zE1++dK5
S3WridqaF9AcCylsdZxrJVqvq0B6Bf5p/qe32Vv37LZHc3mf854GxOog9ic6hIrI
Aw5EJcTC+UZk6+mIaEZCnYAJBJB0ExmPnRSsCr7aVupZWlQ+nETjiiGFUGZfGZZU
8hnJ1bOgSM3hhi1h6o83xZQVDjdLnd8lhu2wzmvKafq7DwOBAupG9jS48xt7S8/t
DGC+miPpVnqvbJMMp9IV59HU6QAJwgBqt6jjqKNEFQc85THwlmysSVL9qgY7RYZw
nSO987g/j3q9skfS3sTyBvFklMEcDtSxdRnVD6BprLAMcNKUzPZbCehnXTiAmuAA
CV9kG1fUNluvVDErlPkbtln3h3870cWW0oGrcxglOCkCpv7d619LED0D8A4P/4sF
PDcz5FQnvkWdXBTcG6DweBeA8Vyj7k0vVVUq3uuig0IsYPBacUy+NM94p5Il4mGv
eR3lwaCo+wxgRVo0WP1U
=JYGG
-----END PGP SIGNATURE-----
--Apple-Mail=_F61FEB8A-306A-4AFF-971B-DA0C6C8EB88F--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 30 Aug 2016 14:03:13 -0700
Raw View
--001a113963f053a7c5053b5050c2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Aug 30, 2016 at 11:40 AM, Howard Hinnant <howard.hinnant@gmail.com>
wrote:
> On Aug 30, 2016, at 2:21 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> >
> > On Tuesday, August 30, 2016 at 10:39:10 AM UTC-4, Howard Hinnant wrote:
> >> On Aug 30, 2016, at 3:56 AM, Myriachan <myri...@gmail.com> wrote:
> >>> >
> >>> >
> >>> >
> >>> > Finally, I've heard that some systems have unusual forms of
> endianness for floating-point numbers but not for integers, or possibly
> having opposite endianness. (Wikipedia lists older ARM systems'
> doubles--perhaps before hardware floating-point in ARM?) How would those
> systems be handled?
> >>>
> >> One of the tried-and-true techniques of standardization is to:
> >>
> >> Standardize existing practice.
> >>
> >> __ORDER_LITTLE_ENDIAN__, __ORDER_BIG_ENDIAN__ and __BYTE_ORDER__ are
> existing practice with at least two major compilers (probably more but I
> don=E2=80=99t have them available to check). This proposal simply packag=
es this
> existing practice using modern C++ tools.
> >>
> > What good is standardizing existing practice if you can't actually say
> what that existing practice means? That's the part that doesn't make sens=
e
> here.
> >
> > The standard specifies behavior. Unless these values are tied into
> genuinely observable behavior, then standardizing them doesn't really
> accomplish anything. And if they are tied into genuinely observable
> behavior, then we need to know what that behavior is.
> >
> > I don't understand the point of standardizing three numbers without
> giving any meaning to these numbers.
>
> I have no doubt that the LWG (or LEWG) will offer improvements to the
> wording. But note that we have been living with the concept of endian in
> the C++ standard for half a decade and the sky hasn=E2=80=99t fallen (yet=
). See
> [locale.stdcvt] for our current use of the terms little endian and big
> endian.
>
> The proposal=E2=80=99s current description of endian is borrowed from wha=
t the
> POSIX standard says about it (http://pubs.opengroup.org/
> onlinepubs/9699919799/basedefs/V1_chap03.html), which seems like a pretty
> good straw man to get the process started. To the best of my knowledge, =
no
> one has complained that the POSIX description of endian is meaningless.
>
POSIX only has to deal with 8-bit bytes and, I think, integer types without
padding, so it has an easier job than C++. That said, your definition seems
clear enough, and LWG can tighten it if they want.
Jeffrey
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANh-dXnGA6iSGqPRFKZX_5eZv4d%2BzBpwEiVD4HmOBnoou=
LuUsQ%40mail.gmail.com.
--001a113963f053a7c5053b5050c2
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 T=
ue, Aug 30, 2016 at 11:40 AM, Howard Hinnant <span dir=3D"ltr"><<a href=
=3D"mailto:howard.hinnant@gmail.com" target=3D"_blank" class=3D"cremed">how=
ard.hinnant@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><span class=3D"">On Aug 30, 2016, at 2:21 PM, Nicol Bolas <<a href=3D=
"mailto:jmckesson@gmail.com" class=3D"cremed">jmckesson@gmail.com</a>> w=
rote:<br>
><br>
> On Tuesday, August 30, 2016 at 10:39:10 AM UTC-4, Howard Hinnant wrote=
:<br>
>> On Aug 30, 2016, at 3:56 AM, Myriachan <<a href=3D"mailto:myri.=
...@gmail.com" class=3D"cremed">myri...@gmail.com</a>> wrote:<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > Finally, I've heard that some systems have unusual fo=
rms of endianness for floating-point numbers but not for integers, or possi=
bly having opposite endianness.=C2=A0 (Wikipedia lists older ARM systems=
9; doubles--perhaps before hardware floating-point in ARM?)=C2=A0 How would=
those systems be handled?<br>
>>><br>
>> One of the tried-and-true techniques of standardization is to:<br>
>><br>
>>=C2=A0 =C2=A0 Standardize existing practice.<br>
>><br>
>> __ORDER_LITTLE_ENDIAN__, __ORDER_BIG_ENDIAN__ and __BYTE_ORDER__ a=
re existing practice with at least two major compilers (probably more but I=
don=E2=80=99t have them available to check).=C2=A0 This proposal simply pa=
ckages this existing practice using modern C++ tools.<br>
>><br>
> What good is standardizing existing practice if you can't actually=
say what that existing practice means? That's the part that doesn'=
t make sense here.<br>
><br>
> The standard specifies behavior. Unless these values are tied into gen=
uinely observable behavior, then standardizing them doesn't really acco=
mplish anything. And if they are tied into genuinely observable behavior, t=
hen we need to know what that behavior is.<br>
><br>
> I don't understand the point of standardizing three numbers withou=
t giving any meaning to these numbers.<br>
<br>
</span>I have no doubt that the LWG (or LEWG) will offer improvements to th=
e wording.=C2=A0 But note that we have been living with the concept of endi=
an in the C++ standard for half a decade and the sky hasn=E2=80=99t fallen =
(yet).=C2=A0 See [locale.stdcvt] for our current use of the terms little en=
dian and big endian.<br>
<br>
The proposal=E2=80=99s current description of endian is borrowed from what =
the POSIX standard says about it (<a href=3D"http://pubs.opengroup.org/onli=
nepubs/9699919799/basedefs/V1_chap03.html" rel=3D"noreferrer" target=3D"_bl=
ank" class=3D"cremed">http://pubs.opengroup.org/<wbr>onlinepubs/9699919799/=
<wbr>basedefs/V1_chap03.html</a>), which seems like a pretty good straw man=
to get the process started.=C2=A0 To the best of my knowledge, no one has =
complained that the POSIX description of endian is meaningless.<br></blockq=
uote><div><br></div><div>POSIX only has to deal with 8-bit bytes and, I thi=
nk, integer types without padding, so it has an easier job than C++. That s=
aid, your definition seems clear enough, and LWG can tighten it if they wan=
t.</div><div><br></div><div>Jeffrey</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dXnGA6iSGqPRFKZX_5eZv4d%2BzBpwEi=
VD4HmOBnoouLuUsQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXnGA6iSGq=
PRFKZX_5eZv4d%2BzBpwEiVD4HmOBnoouLuUsQ%40mail.gmail.com</a>.<br />
--001a113963f053a7c5053b5050c2--
.
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 30 Aug 2016 14:42:31 -0700 (PDT)
Raw View
------=_Part_4797_1190631640.1472593351295
Content-Type: multipart/alternative;
boundary="----=_Part_4798_830991301.1472593351295"
------=_Part_4798_830991301.1472593351295
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, August 30, 2016 at 2:03:37 PM UTC-7, Jeffrey Yasskin wrote:
>
> On Tue, Aug 30, 2016 at 11:40 AM, Howard Hinnant <howard....@gmail.com=20
> <javascript:>> wrote:
>
>> On Aug 30, 2016, at 2:21 PM, Nicol Bolas <jmck...@gmail.com <javascript:=
>>=20
>> wrote:
>> > What good is standardizing existing practice if you can't actually say=
=20
>> what that existing practice means? That's the part that doesn't make sen=
se=20
>> here.
>> >
>> > The standard specifies behavior. Unless these values are tied into=20
>> genuinely observable behavior, then standardizing them doesn't really=20
>> accomplish anything. And if they are tied into genuinely observable=20
>> behavior, then we need to know what that behavior is.
>> >
>> > I don't understand the point of standardizing three numbers without=20
>> giving any meaning to these numbers.
>>
>> I have no doubt that the LWG (or LEWG) will offer improvements to the=20
>> wording. But note that we have been living with the concept of endian i=
n=20
>> the C++ standard for half a decade and the sky hasn=E2=80=99t fallen (ye=
t). See=20
>> [locale.stdcvt] for our current use of the terms little endian and big=
=20
>> endian.
>>
>> The proposal=E2=80=99s current description of endian is borrowed from wh=
at the=20
>> POSIX standard says about it (
>> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html)=
,=20
>> which seems like a pretty good straw man to get the process started. To=
=20
>> the best of my knowledge, no one has complained that the POSIX descripti=
on=20
>> of endian is meaningless.
>>
>
> POSIX only has to deal with 8-bit bytes and, I think, integer types=20
> without padding, so it has an easier job than C++. That said, your=20
> definition seems clear enough, and LWG can tighten it if they want.
>
>
How about the following definition?
A system uses *big-endian* value representation for an integer type T if,=
=20
for any valid value n of type T, after executing the following code, m=20
contains the same value as n:
unsigned char bytes[sizeof(T)];
std::memcpy(bytes, &n, sizeof(T));
T m =3D 0;
for (std::size_t i =3D 0; i < sizeof(T); ++i)
{
m =3D static_cast<T>((m << std::numeric_limits<unsigned char>::digits) =
+=20
bytes[i]);
}
This should work, even with signed types, and non-two's-complement=20
representation. Remember that it's well-defined to shift 1 bits into the=
=20
sign bits of a signed integer (even though any further is undefined).
This would not work in some systems using "nails", but whether such systems=
=20
could really be defined as having a particular standard endianness is=20
itself a question.
Floating-point types could have a definition if=20
std::numeric_limits<T>::is_iec559 is true. If not, the answer is basically=
=20
meaningless from a standardization point of view.
Melissa
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5cbc92c9-02f0-4832-92e7-7f5d14eb5611%40isocpp.or=
g.
------=_Part_4798_830991301.1472593351295
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, August 30, 2016 at 2:03:37 PM UTC-7, Jeffrey Y=
asskin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote">On Tue, Aug 30, 2016 at 11:40 AM, Howard Hi=
nnant <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"Cv25IIMtEgAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascri=
pt:';return true;">howard....@gmail.com</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><span>On Aug 30, 2016, at 2:21 PM, Nicol Bolas <=
;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Cv25IIM=
tEgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';re=
turn true;" onclick=3D"this.href=3D'javascript:';return true;">jmck=
....@gmail.com</a>> wrote:<br>> What good is standardizing existing pr=
actice if you can't actually say what that existing practice means? Tha=
t's the part that doesn't make sense here.<br>
><br>
> The standard specifies behavior. Unless these values are tied into gen=
uinely observable behavior, then standardizing them doesn't really acco=
mplish anything. And if they are tied into genuinely observable behavior, t=
hen we need to know what that behavior is.<br>
><br>
> I don't understand the point of standardizing three numbers withou=
t giving any meaning to these numbers.<br>
<br>
</span>I have no doubt that the LWG (or LEWG) will offer improvements to th=
e wording.=C2=A0 But note that we have been living with the concept of endi=
an in the C++ standard for half a decade and the sky hasn=E2=80=99t fallen =
(yet).=C2=A0 See [locale.stdcvt] for our current use of the terms little en=
dian and big endian.<br>
<br>
The proposal=E2=80=99s current description of endian is borrowed from what =
the POSIX standard says about it (<a href=3D"http://pubs.opengroup.org/onli=
nepubs/9699919799/basedefs/V1_chap03.html" rel=3D"nofollow" target=3D"_blan=
k" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2=
F%2Fpubs.opengroup.org%2Fonlinepubs%2F9699919799%2Fbasedefs%2FV1_chap03.htm=
l\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHx1rzf7WSRaAogPc13hQRtG5ESgg'=
;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dh=
ttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F9699919799%2Fbasedefs%2FV1_ch=
ap03.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHx1rzf7WSRaAogPc13hQRtG5E=
Sgg';return true;">http://pubs.opengroup.org/<wbr>onlinepubs/9699919799=
/<wbr>basedefs/V1_chap03.html</a>), which seems like a pretty good straw ma=
n to get the process started.=C2=A0 To the best of my knowledge, no one has=
complained that the POSIX description of endian is meaningless.<br></block=
quote><div><br></div><div>POSIX only has to deal with 8-bit bytes and, I th=
ink, integer types without padding, so it has an easier job than C++. That =
said, your definition seems clear enough, and LWG can tighten it if they wa=
nt.</div><br></div></div></div></blockquote><div><br>How about the followin=
g definition?<br><br>A system uses <i>big-endian</i> value representation f=
or an integer type <span style=3D"font-family: courier new,monospace;">T</s=
pan> if, for any valid value <span style=3D"font-family: courier new,monosp=
ace;">n</span> of type <span style=3D"font-family: courier new,monospace;">=
T</span>, after executing the following code, <span style=3D"font-family: c=
ourier new,monospace;">m</span> contains the same value as <span style=3D"f=
ont-family: courier new,monospace;">n</span>:<br><br><div class=3D"prettypr=
int" 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"prettyprint"><div class=3D"subprettyprint"><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">unsigned</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">char</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> bytes</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">[</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">sizeof</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)];</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>std</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">memcpy</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">bytes</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">,</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-pret=
tify">n</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">));</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>T m </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">for</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: #0=
00;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">size_t i </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> i </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">sizeof</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">+=
+</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 m </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">static_cast</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">>((</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">m </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y"><<</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">numeric_limit=
s</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">unsigned</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">char</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">>::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">digits</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">+</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> bytes</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">]);</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br><b=
r>This should work, even with signed types, and non-two's-complement re=
presentation.=C2=A0 Remember that it's well-defined to shift 1 bits int=
o the sign bits of a signed integer (even though any further is undefined).=
<br><br>This would not work in some systems using "nails", but wh=
ether such systems could really be defined as having a particular standard =
endianness is itself a question.<br><br>Floating-point types could have a d=
efinition if <span style=3D"font-family: courier new,monospace;">std::numer=
ic_limits<T>::is_iec559</span> is <span style=3D"font-family: courier=
new,monospace;">true</span>.=C2=A0 If not, the answer is basically meaning=
less from a standardization point of view.<br><br>Melissa<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5cbc92c9-02f0-4832-92e7-7f5d14eb5611%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5cbc92c9-02f0-4832-92e7-7f5d14eb5611=
%40isocpp.org</a>.<br />
------=_Part_4798_830991301.1472593351295--
------=_Part_4797_1190631640.1472593351295--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Tue, 30 Aug 2016 17:55:22 -0400
Raw View
--Apple-Mail=_264CDA61-16E2-419A-A5C8-72396E6E330A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
On Aug 30, 2016, at 5:42 PM, Myriachan <myriachan@gmail.com> wrote:
>=20
> How about the following definition?
>=20
> A system uses big-endian value representation for an integer type T if, f=
or any valid value n of type T, after executing the following code, m conta=
ins the same value as n:
>=20
> unsigned char bytes[sizeof(T)];
> std::memcpy(bytes, &n, sizeof(T));
> T m =3D 0;
> for (std::size_t i =3D 0; i < sizeof(T); ++i)
> {
> m =3D static_cast<T>((m << std::numeric_limits<unsigned char>::digits=
) + bytes[i]);
> }
>=20
>=20
> This should work, even with signed types, and non-two's-complement repres=
entation. Remember that it's well-defined to shift 1 bits into the sign bi=
ts of a signed integer (even though any further is undefined).
>=20
> This would not work in some systems using "nails", but whether such syste=
ms could really be defined as having a particular standard endianness is it=
self a question.
>=20
> Floating-point types could have a definition if std::numeric_limits<T>::i=
s_iec559 is true. If not, the answer is basically meaningless from a stand=
ardization point of view.
That looks reasonable to me. I would want the language lawyers over in SG1=
2 (Undefined and Unspecified Behavior) to look at it though. I keep loosin=
g track of what=E2=80=99s UB and what=E2=80=99s not.
Howard
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/30D029CD-59DD-4B30-814F-0255ADBBDA92%40gmail.com=
..
--Apple-Mail=_264CDA61-16E2-419A-A5C8-72396E6E330A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJXxgDKAAoJEGbcHCxKqhWCEzMP/j6HeYfsU5eoyerkjxvAr0Ha
HmJz14MsN903V1xOU8esx5gy6AfBnUP8qtpTMC8vP4TpgrQTp+HSbOpgpUqlMO7i
WlbaknDBLHZCOFQsNP/NhrSuqynTqSSTxz5T7hq64FJgG4k0O/hkos6VDzHm9ELq
5tp9+7l2RNXbpmh0jZXilhNNS/Wr7WwBxDBR3m7HzAsT7CxLSjz+q1Rl7FRmTBHb
Ul5G0c92T6sMXiLYPmY8rRXu5/Xt0OIDJSRPhwssw5yIuZqj57gCEkrx3s6QMtWJ
GPgyOCmRta/P93OJ1jhjU0tRXAMow2xD4+1f9BW0WnpEmLxUpnPRTmKv/Azi8vBp
eXtk5E8EZl7/Kn9Qg+k7wAg/IidqCo9odiW1TYDKnCuEb9go4II3WG2K2pjElgtY
lqLVsEq1pRmlz5DVBrlAYhoze6UE0QghiM6xNOEn9C2rsYC8RI0hm/QDt4eHUWSn
cWOx44VE+QXiiCvVoOcbnOkl+ozXbVE1tXEZeI/j8EuER0vsUDe3j/HXv8DvjzET
r0DgqTTDZCpV5G06Fmrb1v/sDGDqlt6JJYt025CxALjETOxFh8qSm+zgWLRydGFN
Pni9DWmD8KANmvcAes4yBJWmKEPXoMZh7x7d97FGYgWrKYfjJcBeAClo7CZEhfq+
IyBCYnDB6arRIGLNUn5W
=OMam
-----END PGP SIGNATURE-----
--Apple-Mail=_264CDA61-16E2-419A-A5C8-72396E6E330A--
.