------=_Part_4644_20755413.1380686170291
Content-Type: text/plain; charset=ISO-8859-1

This proposal should be generalized to a more generic byte swapping
solution. Something like:

//<bswap>
//Endianness
struct byte_order {
  enum order {
     little_endian,
     big_endian,
  };
order value = /*implementation defined*/;
};

//Cross-platform Byteswapping
template <typename T> constexpr T bswap(T val);
template <typename T> constexpr T cpu_to_be(T val) {
  return byte_order::value == little_endian ? bswap(val) : val;
}
template <typename T> constexpr T cpu_to_le(T val) {
  return byte_order::value == little_endian ? val : bswap(val);
}

//<net>

#include <bswap>
//Network byte order layer built ontop of bswap
template <typename T> constexpr T hton(T val) { return cpu_to_be(val); }

This is so easy and trivial to implement. Most compilers even have builtins
for all of the byte swapping routines. I don't know why its not
standardized.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4644_20755413.1380686170291
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>This proposal should be generalized to a more generic=
 byte swapping solution. Something like:</div><div><br></div><div>//&lt;bsw=
ap&gt;</div><div>//Endianness</div><div><div>struct byte_order {</div><div>=
&nbsp; enum order {</div><div>&nbsp; &nbsp; &nbsp;little_endian,</div><div>=
&nbsp; &nbsp; &nbsp;big_endian,<br>&nbsp; };</div><div>order value =3D /*im=
plementation defined*/;</div><div>};</div></div><div><br></div><div>//Cross=
-platform Byteswapping</div><div>template &lt;typename T&gt; constexpr T bs=
wap(T val);</div><div>template &lt;typename T&gt; constexpr T cpu_to_be(T v=
al) {</div><div>&nbsp; return byte_order::value =3D=3D little_endian ? bswa=
p(val) : val;<br>}</div><div>template &lt;typename T&gt; constexpr T cpu_to=
_le(T val) {</div><div>&nbsp; return byte_order::value =3D=3D little_endian=
 ? val : bswap(val);<br>}</div><div><br></div><div>//&lt;net&gt;</div><div>=
<br></div><div>#include &lt;bswap&gt;</div><div>//Network byte order layer =
built ontop of bswap</div><div>template &lt;typename T&gt; constexpr T hton=
(T val) { return cpu_to_be(val); }</div><div><br></div><div>This is so easy=
 and trivial to implement. Most compilers even have builtins for all of the=
 byte swapping routines. I don't know why its not standardized.</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4644_20755413.1380686170291--

.

--f46d043d65571b841604e7ba19f6
Content-Type: text/plain; charset=ISO-8859-1

On 2 October 2013 06:56, <fmatthew5876@gmail.com> wrote:

> This proposal should be generalized to a more generic byte swapping
> solution. Something like:
>

We know. :)


> This is so easy and trivial to implement. Most compilers even have
> builtins for all of the byte swapping routines. I don't know why its not
> standardized.
>
>
>
It's not standardized because networking didn't need the generic solution
and I don't recall
seeing a proposal for the generic one.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--f46d043d65571b841604e7ba19f6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 2 October 2013 06:56,  <span dir=3D"ltr">&lt;<a href=3D"mailto:f=
matthew5876@gmail.com" target=3D"_blank">fmatthew5876@gmail.com</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>This proposal should b=
e generalized to a more generic byte swapping solution. Something like:</di=
v>
</div></blockquote><div><br></div><div>We know. :)<br>=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div></div><div>This is so easy and tri=
vial to implement. Most compilers even have builtins for all of the byte sw=
apping routines. I don&#39;t know why its not standardized.</div>
</div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

<br></font></span></blockquote><div><br></div><div>It&#39;s not standardize=
d because networking didn&#39;t need the generic solution and I don&#39;t r=
ecall<br>seeing a proposal for the generic one. <br></div></div><br></div>
</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--f46d043d65571b841604e7ba19f6--

.

------=_Part_223_25286319.1380863115174
Content-Type: text/plain; charset=ISO-8859-1



> It's not standardized because networking didn't need the generic solution
> and I don't recall
> seeing a proposal for the generic one.
>
>
In that case I'd like to work on making one. Its a pretty small thing so it
should not be difficult.
Here is an example of what it might look like:
https://github.com/fmatthew5876/stdcxx/blob/master/byteorder/include/byteorder.hh

Anyone care to comment or add suggestions?

Thanks!

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_223_25286319.1380863115174
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div>It's not standardized because=
 networking didn't need the generic solution and I don't recall<br>seeing a=
 proposal for the generic one. <br></div></div><br></div></div></blockquote=
><div><br></div><div>In that case I'd like to work on making one. Its a pre=
tty small thing so it should not be difficult.</div><div>Here is an example=
 of what it might look like:</div><div>https://github.com/fmatthew5876/stdc=
xx/blob/master/byteorder/include/byteorder.hh</div><div><br></div><div>Anyo=
ne care to comment or add suggestions?&nbsp;</div><div><br></div><div>Thank=
s!</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_223_25286319.1380863115174--

.

------=_Part_176_18627928.1380869700759
Content-Type: text/plain; charset=ISO-8859-1

I am strongly against hton and ntoh. There is no single fixed network
byteorder. Byteorder depends on the underlying protocol.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_176_18627928.1380869700759
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">I am strongly against hton and ntoh. There is no single fixed network byteorder. Byteorder depends on the underlying protocol.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_176_18627928.1380869700759--

.

On quinta-feira, 3 de outubro de 2013 23:55:00, stackmachine@hotmail.com
wrote:
> I am strongly against hton and ntoh. There is no single fixed network
> byteorder. Byteorder depends on the underlying protocol.

You're at least 20 years too late on that argument.

"Network byte order" has been established for ages as "big endian". The htonl
and htons function have existed since the 1980s in one form or another.

That said, we need conversions to/from little endian as well, since many
protocols currently use (and future ones might too) little-endian, especially
since the most consumer-grade CPUs operate in little-endian mode.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_451_22539723.1380887723631
Content-Type: text/plain; charset=ISO-8859-1



On Friday, October 4, 2013 2:55:00 AM UTC-4, stackm...@hotmail.com wrote:
>
> I am strongly against hton and ntoh. There is no single fixed network
> byteorder. Byteorder depends on the underlying protocol.
>

The "internet" is big endian. Unless we move away from tcp/ip and replace
all of our switches and routers this will not change anytime soon.
hton() is a good abstraction, but it needs to be built on top of a more
generic solution. Many people deal with binary files
and hardware devices. These can require either little or big endian file
formats.

byteswapping is really about cross platform binary data formats. Networking
is only one user.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_451_22539723.1380887723631
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, October 4, 2013 2:55:00 AM UTC-4, stack=
m...@hotmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">I am strongly against hton and ntoh. There is no single fixed net=
work byteorder. Byteorder depends on the underlying protocol.<br></div></bl=
ockquote><div><br></div><div>The "internet" is big endian. Unless we move a=
way from tcp/ip and replace all of our switches and routers this will not c=
hange anytime soon.</div><div>hton() is a good abstraction, but it needs to=
 be built on top of a more generic solution. Many people deal with binary f=
iles</div><div>and hardware devices. These can require either little or big=
 endian file formats.</div><div><br></div><div>byteswapping is really about=
 cross platform binary data formats. Networking is only one user.&nbsp;</di=
v></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_451_22539723.1380887723631--

.

On 10/04/2013 07:05 AM, fmatthew5876@gmail.com wrote:
>
>     It's not standardized because networking didn't need the generic
>     solution and I don't recall
>     seeing a proposal for the generic one.
>
>
> In that case I'd like to work on making one. Its a pretty small thing so
> it should not be difficult.
> Here is an example of what it might look like:
> https://github.com/fmatthew5876/stdcxx/blob/master/byteorder/include/byteorder.hh
>
> Anyone care to comment or add suggestions?
>
> Thanks!
>
> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

Thanks for your interest in making a proposal. As I am interested in
this topic too, I want to help you with this.

> struct byte_order {
>   enum order {
>     little_endian = 1234,
>     big_endian = 4321,
>     //Optional: pdp endian? Linux defines this.
>     pdp_endian = 3412,
>   };
>   constexpr static order value = little_endian; //Implementation defined value little_endian or big_endian.
> };

Is there a reason for these specific numbers (e.g. little_endian =
1234)? Using smaller numbers (0,1,...) would enable us to store the
values in a smaller data type (e.g. char).

Intentionally I would write the above as:

enum class byte_order
//enum class byte_order : unsigned char (if size matters)
{
     little_endian = 0,
     big_endian = 1,
     native_endian = little_endian //Implementation defined
};

I cannot say if it is betters or worse. What is your opinion about it?

> constexpr uint16_t bswap(uint16_t v) {
>   return __builtin_bswap16(v);
> }

I didn't know that __builtin_bswap could be used as a constexpr. Awesome!

> constexpr uint16_t bswap16(uint16_t t) { return bswap(t); }

I would prefer a template for bswap:
template <typename T>
constexpr T bswap(T x); //Only specialized for supported types

This enables the following usages:
uint16_t x = bswap<uint16_t>(5);
uint16_t y = bswap(x);

> template <typename T>
> constexpr T cpu_to_le(T t) { return byte_order::value == byte_order::little_endian ? t : bswap(t); }

I personally would prefer the wording 'native' to 'cpu'.
I would move the byte_orders to template arguments (either as addition,
or as a replacement of the above):

template <byte_order from, byte_order to, typename T>
constexpr T convertByteOrder(T t);

> //Optional: Should we support signed integers as well?

IMHO yes!

> //Optional: Should we support floating point types? Do binary formats or hardware devices need this?

Yes, I am sure someone will someday create a format that needs this (If
it is not already existing).

Question: Is there any architecture where integers and floating point
numbers are stored in different endianesses?

> //Optional: Byte Swapping an arbitrary sized buffer? Is this at all useful?

I am not sure about this either. At least all supported integral types
should be supported.

Note: For buffers std::reverse_copy could be used to realize bswap.

> //Optional: Do we need/want a macro interface?

I think we you have it!

What I've been missing is a function the convert the byte_order without
knowing the order during compilation time. e.g:

template<typename T>
constexpr T convertByteOrderRT(T t, byte_order from, byte_order to);

byte_order from = ??; // Is set during runtime

uint16_t x = convertByteOrderRT(v, from, little_endian);

This function could also replace the 'convertByteOrder' function
mentioned above.

Some corner cases we probably should not care about:
- Swapping of types with sizes like 6 Byte
- Behavior when CHAR_BITS != 8


I hope these remarks are helpful for you and welcome any feedback.


regards, Markus









--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On sexta-feira, 4 de outubro de 2013 14:51:45, Markus Mayer wrote:
> Is there a reason for these specific numbers (e.g. little_endian =
> 1234)? Using smaller numbers (0,1,...) would enable us to store the
> values in a smaller data type (e.g. char).

Historic, from BSD. See endian.h.

There's also a third possible value used historically too. endian.h calls it
PDP_ENDIAN and its value is 3412. I've also seen it called "boustrophedon byte
order", but I guess no one can remember how to spell that (I had to look it
up).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_1308_30128354.1380945245021
Content-Type: text/plain; charset=ISO-8859-1



On Friday, October 4, 2013 8:51:45 AM UTC-4, Markus Mayer wrote:
>
> On 10/04/2013 07:05 AM, fmatth...@gmail.com <javascript:> wrote:
> >
> >     It's not standardized because networking didn't need the generic
> >     solution and I don't recall
> >     seeing a proposal for the generic one.
> >
> >
> > In that case I'd like to work on making one. Its a pretty small thing so
> > it should not be difficult.
> > Here is an example of what it might look like:
> >
> https://github.com/fmatthew5876/stdcxx/blob/master/byteorder/include/byteorder.hh
> >
> > Anyone care to comment or add suggestions?
> >
> > Thanks!
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google
> > Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> > an email to std-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>
> > Visit this group at
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> Thanks for your interest in making a proposal. As I am interested in
> this topic too, I want to help you with this.
>
> > struct byte_order {
> >   enum order {
> >     little_endian = 1234,
> >     big_endian = 4321,
> >     //Optional: pdp endian? Linux defines this.
> >     pdp_endian = 3412,
> >   };
> >   constexpr static order value = little_endian; //Implementation defined
> value little_endian or big_endian.
> > };
>
> Is there a reason for these specific numbers (e.g. little_endian =
> 1234)? Using smaller numbers (0,1,...) would enable us to store the
> values in a smaller data type (e.g. char).
>
> Intentionally I would write the above as:
>
> enum class byte_order
> //enum class byte_order : unsigned char (if size matters)
> {
>      little_endian = 0,
>      big_endian = 1,
>      native_endian = little_endian //Implementation defined
> };
>

This is much better actually. native_endian should be the same enum type.
 This opens more possibility and freedom in implementing templates,
functions, and switch statements.
Also while I like the style of the 1234 and 4321, 0 and 1 are better. That
allows using the enums as array indicies for free.

Maybe this?
enum class endian {
  little,
  big,
  native = little
};

>
> I cannot say if it is betters or worse. What is your opinion about it?
>
> > constexpr uint16_t bswap(uint16_t v) {
> >   return __builtin_bswap16(v);
> > }
>
> I didn't know that __builtin_bswap could be used as a constexpr. Awesome!
>
> I haven't actually tested this for sure, but it compiles. Anyway the
purpose is just to make the point that most compilers already do this
trivially.



> > constexpr uint16_t bswap16(uint16_t t) { return bswap(t); }
>
> I would prefer a template for bswap:
> template <typename T>
> constexpr T bswap(T x); //Only specialized for supported types
>
> This enables the following usages:
> uint16_t x = bswap<uint16_t>(5);
> uint16_t y = bswap(x);
>
> I'm sold, that by far the most elegant way to handle type conversions.



> > template <typename T>
> > constexpr T cpu_to_le(T t) { return byte_order::value ==
> byte_order::little_endian ? t : bswap(t); }
>
> I personally would prefer the wording 'native' to 'cpu'.
> I would move the byte_orders to template arguments (either as addition,
> or as a replacement of the above):
>

host is also another possibility. Naming is hard, lets think more, we have
time.


>
> template <byte_order from, byte_order to, typename T>
> constexpr T convertByteOrder(T t);
>
>
This I'm not sure I agree with. It's incredibly wordy and I'm not sure what
the template arguments buy you. Most of the time people just want to
convert to either le or be.
So almost all of the time one of the arguments will be native. When the
user wants to do a strict conversion, he can just use bswap directly.
Also a short name I think is important here, especially if used for setting
up tables of constexpr values. For example is a list of device driver

Imagine a header file for a device driver which has a large table of big
endian 32 bit oridinal commands.

//device.hh
enum : uint32_t {
  kOrdOpen = cpu_to_be(5UL),
  kOrdClose = cpu_to_be(6UL)
};

The above is consise. Spelling it out with templates would be redundant and
tiresome.

> //Optional: Should we support signed integers as well?
>
> IMHO yes!
>
Ok I agree

>
> > //Optional: Should we support floating point types? Do binary formats or
> hardware devices need this?
>
> Yes, I am sure someone will someday create a format that needs this (If
> it is not already existing).
>
> Question: Is there any architecture where integers and floating point
> numbers are stored in different endianesses?
>

Never heard of that, but if its possible there can be separate int and
float endian enums like we have above.
I don't think that adds very much complexity. In the meantime, we should
have them in.


> > //Optional: Byte Swapping an arbitrary sized buffer? Is this at all
> useful?
>
> I am not sure about this either. At least all supported integral types
> should be supported.
>
> Note: For buffers std::reverse_copy could be used to realize bswap.
>
> > //Optional: Do we need/want a macro interface?
>
> I think we you have it!
>
> What I've been missing is a function the convert the byte_order without
> knowing the order during compilation time. e.g:
>
> template<typename T>
> constexpr T convertByteOrderRT(T t, byte_order from, byte_order to);
>
> byte_order from = ??; // Is set during runtime
>
> uint16_t x = convertByteOrderRT(v, from, little_endian);
>
> This function could also replace the 'convertByteOrder' function
> mentioned above.
>

runtime control makes sense.


>
> Some corner cases we probably should not care about:
> - Swapping of types with sizes like 6 Byte
>
Just reverse the bytes I suppose, what else would you do.


> - Behavior when CHAR_BITS != 8
>
byte swapping is about bytes not bits. So I think we can safely ignore this
horrible issue.


>
>
> I hope these remarks are helpful for you and welcome any feedback.
>
> Thanks for your suggestions!

>
> regards, Markus
>
>
>
> New version of header on github.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1308_30128354.1380945245021
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, October 4, 2013 8:51:45 AM UTC-4, Marku=
s Mayer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10/04/2013 07=
:05 AM, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
mNmOBhwnOVwJ">fmatth...@gmail.com</a> wrote:
<br>&gt;
<br>&gt; &nbsp; &nbsp; It's not standardized because networking didn't need=
 the generic
<br>&gt; &nbsp; &nbsp; solution and I don't recall
<br>&gt; &nbsp; &nbsp; seeing a proposal for the generic one.
<br>&gt;
<br>&gt;
<br>&gt; In that case I'd like to work on making one. Its a pretty small th=
ing so
<br>&gt; it should not be difficult.
<br>&gt; Here is an example of what it might look like:
<br>&gt; <a href=3D"https://github.com/fmatthew5876/stdcxx/blob/master/byte=
order/include/byteorder.hh" target=3D"_blank">https://github.com/<wbr>fmatt=
hew5876/stdcxx/blob/<wbr>master/byteorder/include/<wbr>byteorder.hh</a>
<br>&gt;
<br>&gt; Anyone care to comment or add suggestions?
<br>&gt;
<br>&gt; Thanks!
<br>&gt;
<br>&gt; --
<br>&gt;
<br>&gt; ---
<br>&gt; You received this message because you are subscribed to the Google
<br>&gt; Groups "ISO C++ Standard - Future Proposals" group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send
<br>&gt; an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"mNmOBhwnOVwJ">std-proposal...@<wbr>isocpp.org</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"mNmOBhwnOVwJ">std-pr...@isocpp.org</a=
>.
<br>&gt; Visit this group at
<br>&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.org/group/std=
-<wbr>proposals/</a>.
<br>
<br>Thanks for your interest in making a proposal. As I am interested in=20
<br>this topic too, I want to help you with this.
<br>
<br>&gt; struct byte_order {
<br>&gt; &nbsp; enum order {
<br>&gt; &nbsp; &nbsp; little_endian =3D 1234,
<br>&gt; &nbsp; &nbsp; big_endian =3D 4321,
<br>&gt; &nbsp; &nbsp; //Optional: pdp endian? Linux defines this.
<br>&gt; &nbsp; &nbsp; pdp_endian =3D 3412,
<br>&gt; &nbsp; };
<br>&gt; &nbsp; constexpr static order value =3D little_endian; //Implement=
ation defined value little_endian or big_endian.
<br>&gt; };
<br>
<br>Is there a reason for these specific numbers (e.g. little_endian =3D=20
<br>1234)? Using smaller numbers (0,1,...) would enable us to store the=20
<br>values in a smaller data type (e.g. char).
<br>
<br>Intentionally I would write the above as:
<br>
<br>enum class byte_order
<br>//enum class byte_order : unsigned char (if size matters)
<br>{
<br>&nbsp; &nbsp; &nbsp;little_endian =3D 0,
<br>&nbsp; &nbsp; &nbsp;big_endian =3D 1,
<br>&nbsp; &nbsp; &nbsp;native_endian =3D little_endian //Implementation de=
fined
<br>};
<br></blockquote><div><br></div><div>This is much better actually. native_e=
ndian should be the same enum type. &nbsp;This opens more possibility and f=
reedom in implementing templates, functions, and switch statements.</div><d=
iv>Also while I like the style of the 1234 and 4321, 0 and 1 are better. Th=
at allows using the enums as array indicies for free.</div><div><br></div><=
div>Maybe this?</div><div>enum class endian {</div><div>&nbsp; little,</div=
><div>&nbsp; big,</div><div>&nbsp; native =3D little<br>};</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">
<br>I cannot say if it is betters or worse. What is your opinion about it?
<br>
<br>&gt; constexpr uint16_t bswap(uint16_t v) {
<br>&gt; &nbsp; return __builtin_bswap16(v);
<br>&gt; }
<br>
<br>I didn't know that __builtin_bswap could be used as a constexpr. Awesom=
e!
<br>
<br></blockquote><div>I haven't actually tested this for sure, but it compi=
les. Anyway the purpose is just to make the point that most compilers alrea=
dy do this trivially.</div><div><br></div><div>&nbsp;</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">&gt; constexpr uint16_t bswap16(uint16_t t) { =
return bswap(t); }
<br>
<br>I would prefer a template for bswap:
<br>template &lt;typename T&gt;
<br>constexpr T bswap(T x); //Only specialized for supported types
<br>
<br>This enables the following usages:
<br>uint16_t x =3D bswap&lt;uint16_t&gt;(5);
<br>uint16_t y =3D bswap(x);
<br>
<br></blockquote><div>I'm sold, that by far the most elegant way to handle =
type conversions.</div><div><br></div><div>&nbsp;</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">&gt; template &lt;typename T&gt;
<br>&gt; constexpr T cpu_to_le(T t) { return byte_order::value =3D=3D byte_=
order::little_endian ? t : bswap(t); }
<br>
<br>I personally would prefer the wording 'native' to 'cpu'.
<br>I would move the byte_orders to template arguments (either as addition,=
=20
<br>or as a replacement of the above):
<br></blockquote><div><br></div><div>host is also another possibility. Nami=
ng is hard, lets think more, we have time.</div><div>&nbsp;</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">
<br>template &lt;byte_order from, byte_order to, typename T&gt;
<br>constexpr T convertByteOrder(T t);
<br>
<br></blockquote><div><br></div><div>This I'm not sure I agree with. It's i=
ncredibly wordy and I'm not sure what the template arguments buy you. Most =
of the time people just want to convert to either le or be.&nbsp;</div><div=
>So almost all of the time one of the arguments will be native. When the us=
er wants to do a strict conversion, he can just use bswap directly.</div><d=
iv>Also a short name I think is important here, especially if used for sett=
ing up tables of constexpr values. For example is a list of device driver</=
div><div><br></div><div>Imagine a header file for a device driver which has=
 a large table of big endian 32 bit oridinal commands.</div><div><br></div>=
<div>//device.hh</div><div>enum : uint32_t {<br>&nbsp; kOrdOpen =3D cpu_to_=
be(5UL),</div><div>&nbsp; kOrdClose =3D cpu_to_be(6UL)</div><div>};</div><d=
iv><br></div><div>The above is consise. Spelling it out with templates woul=
d be redundant and tiresome.</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">&gt; //Optional: Should we support signed integers as we=
ll?
<br>
<br>IMHO yes!
<br></blockquote><div>Ok I agree&nbsp;</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">
<br>&gt; //Optional: Should we support floating point types? Do binary form=
ats or hardware devices need this?
<br>
<br>Yes, I am sure someone will someday create a format that needs this (If=
=20
<br>it is not already existing).
<br>
<br>Question: Is there any architecture where integers and floating point=
=20
<br>numbers are stored in different endianesses?
<br></blockquote><div><br></div><div>Never heard of that, but if its possib=
le there can be separate int and float endian enums like we have above.&nbs=
p;</div><div>I don't think that adds very much complexity. In the meantime,=
 we should have them in.</div><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">
<br>&gt; //Optional: Byte Swapping an arbitrary sized buffer? Is this at al=
l useful?
<br>
<br>I am not sure about this either. At least all supported integral types=
=20
<br>should be supported.
<br>
<br>Note: For buffers std::reverse_copy could be used to realize bswap.
<br>
<br>&gt; //Optional: Do we need/want a macro interface?
<br>
<br>I think we you have it!
<br>
<br>What I've been missing is a function the convert the byte_order without=
=20
<br>knowing the order during compilation time. e.g:
<br>
<br>template&lt;typename T&gt;
<br>constexpr T convertByteOrderRT(T t, byte_order from, byte_order to);
<br>
<br>byte_order from =3D ??; // Is set during runtime
<br>
<br>uint16_t x =3D convertByteOrderRT(v, from, little_endian);
<br>
<br>This function could also replace the 'convertByteOrder' function=20
<br>mentioned above.
<br></blockquote><div><br></div><div>runtime control makes sense.</div><div=
>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Some corner cases we probably should not care about:
<br>- Swapping of types with sizes like 6 Byte
<br></blockquote><div>Just reverse the bytes I suppose, what else would you=
 do.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">- B=
ehavior when CHAR_BITS !=3D 8
<br></blockquote><div>byte swapping is about bytes not bits. So I think we =
can safely ignore this horrible issue.</div><div>&nbsp;</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">
<br>
<br>I hope these remarks are helpful for you and welcome any feedback.
<br>
<br></blockquote><div>Thanks for your suggestions!&nbsp;</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">
<br>regards, Markus
<br>
<br>
<br><br></blockquote><div>New version of header on github.&nbsp;</div></div=
>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1308_30128354.1380945245021--

.

On 10/05/2013 05:54 AM, fmatthew5876@gmail.com wrote:

> New version of header on github.

I suggest that you rename the cpu_to_* and *_to_cpu functions, because
not all operating systems (e.g. Stratus VOS) use the same endianness as
the CPU.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_1590_4318096.1380978844463
Content-Type: text/plain; charset=ISO-8859-1



On Saturday, October 5, 2013 8:50:16 AM UTC-4, Bjorn Reese wrote:
>
> On 10/05/2013 05:54 AM, fmatth...@gmail.com <javascript:> wrote:
>
> > New version of header on github.
>
> I suggest that you rename the cpu_to_* and *_to_cpu functions, because
> not all operating systems (e.g. Stratus VOS) use the same endianness as
> the CPU.
>
>
I can agree with that. I've changed the name to host for the moment. Still
open to possibly using native or some other name.
One other benefit of host is that it matches hton() naming scheme.

Maybe the byte_order enum value should also match? This makes the link
between them a little more clear. byte_order::host/host_to_Xe or
byte_order::native/native_to_Xe

We could also shorten the names even further:
htole()
htobe()
letoh()
betoh()

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1590_4318096.1380978844463
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, October 5, 2013 8:50:16 AM UTC-4, Bjo=
rn Reese wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10/05/2013 0=
5:54 AM, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"G5QMHKOWE9YJ">fmatth...@gmail.com</a> wrote:
<br>
<br>&gt; New version of header on github.
<br>
<br>I suggest that you rename the cpu_to_* and *_to_cpu functions, because
<br>not all operating systems (e.g. Stratus VOS) use the same endianness as
<br>the CPU.
<br>
<br></blockquote><div><br>I can agree with that. I've changed the name to h=
ost for the moment. Still open to possibly using native or some other name.=
</div><div>One other benefit of host is that it matches hton() naming schem=
e.</div><div><br></div><div>Maybe the byte_order enum value should also mat=
ch? This makes the link between them a little more clear. byte_order::host/=
host_to_Xe or byte_order::native/native_to_Xe</div><div><br></div><div>We c=
ould also shorten the names even further:</div><div>htole()</div><div>htobe=
()</div><div>letoh()</div><div>betoh()&nbsp;</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1590_4318096.1380978844463--

.

--089e0112c5182067b904e7fee515
Content-Type: text/plain; charset=ISO-8859-1

On 5 October 2013 16:14, <fmatthew5876@gmail.com> wrote:

>
> We could also shorten the names even further:
> htole()
> htobe()
> letoh()
> betoh()
>
>
>
>
Perhaps we should try to make them readable. htons and ntohs are bad
examples to follow
in that regard.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0112c5182067b904e7fee515
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 5 October 2013 16:14,  <span dir=3D"ltr">&lt;<a href=3D"mailto:f=
matthew5876@gmail.com" target=3D"_blank">fmatthew5876@gmail.com</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>We could also shor=
ten the names even further:</div><div>htole()</div><div>htobe()</div><div>l=
etoh()</div>
<div>betoh()=A0</div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>Perhaps we should try =
to make them readable. htons and ntohs are bad examples to follow<br>in tha=
t regard. <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0112c5182067b904e7fee515--

.

On 10/05/2013 03:14 PM, fmatthew5876@gmail.com wrote:
>
>
> On Saturday, October 5, 2013 8:50:16 AM UTC-4, Bjorn Reese wrote:
>
>     On 10/05/2013 05:54 AM, fmatth...@gmail.com <javascript:> wrote:
>
>      > New version of header on github.
>
>     I suggest that you rename the cpu_to_* and *_to_cpu functions, because
>     not all operating systems (e.g. Stratus VOS) use the same endianness as
>     the CPU.
>
>
> I can agree with that. I've changed the name to host for the moment.
> Still open to possibly using native or some other name.
> One other benefit of host is that it matches hton() naming scheme.
>
> Maybe the byte_order enum value should also match? This makes the link
> between them a little more clear. byte_order::host/host_to_Xe or
> byte_order::native/native_to_Xe
>

Irregardless if we call it 'native', 'host' or anything else, the enum
value should match the *_to_Xe functions. Everything else would be
irritating.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 10/05/2013 04:04 PM, Ville Voutilainen wrote:
>
>
>
> On 5 October 2013 16:14, <fmatthew5876@gmail.com
> <mailto:fmatthew5876@gmail.com>> wrote:
>
>
>     We could also shorten the names even further:
>     htole()
>     htobe()
>     letoh()
>     betoh()
>
>
>
>
> Perhaps we should try to make them readable. htons and ntohs are bad
> examples to follow
> in that regard.
>

+1 for readability.

I also suggest to rename the bswap template to 'byte_swap' or even
'swap_bytes'.

The same holds for 'bconvert' ('byte_convert' or 'convert_bytes').


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_145_11442410.1380990875114
Content-Type: text/plain; charset=ISO-8859-1



On Saturday, October 5, 2013 12:14:30 PM UTC-4, Markus Mayer wrote:
>
> On 10/05/2013 04:04 PM, Ville Voutilainen wrote:
> >
> >
> >
> > On 5 October 2013 16:14, <fmatth...@gmail.com <javascript:>
> > <mailto:fmatth...@gmail.com <javascript:>>> wrote:
> >
> >
> >     We could also shorten the names even further:
> >     htole()
> >     htobe()
> >     letoh()
> >     betoh()
> >
> >
> >
> >
> > Perhaps we should try to make them readable. htons and ntohs are bad
> > examples to follow
> > in that regard.
> >
>
> +1 for readability.
>
>
99% of the time I agree. However I do view these kinds of bit/byte
operations as primitives, also even the same as operators like +, |, <<,
etc..
These kinds of things are the only place I'd prefer short names to avoid
typing, especially if they are being combined in an expression.


> I also suggest to rename the bswap template to 'byte_swap' or even
> 'swap_bytes'.
>
Usually for function names, I prefer verbs to go first. So swap_bytes would
be preferrable. I'm not totally opposed to bswap() though for reasons
mentioned above.


>
> The same holds for 'bconvert' ('byte_convert' or 'convert_bytes').
>
> This was a bad name, now there is a new one.

Updates in git.



--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_145_11442410.1380990875114
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, October 5, 2013 12:14:30 PM UTC-4, Ma=
rkus Mayer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10/05/2013=
 04:04 PM, Ville Voutilainen wrote:
<br>&gt;
<br>&gt;
<br>&gt;
<br>&gt; On 5 October 2013 16:14, &lt;<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"8chg7_NgFgkJ">fmatth...@gmail.com</a>
<br>&gt; &lt;mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"8chg7_NgFgkJ">fmatth...@gmail.com</a><wbr>&gt;&gt; wrote:
<br>&gt;
<br>&gt;
<br>&gt; &nbsp; &nbsp; We could also shorten the names even further:
<br>&gt; &nbsp; &nbsp; htole()
<br>&gt; &nbsp; &nbsp; htobe()
<br>&gt; &nbsp; &nbsp; letoh()
<br>&gt; &nbsp; &nbsp; betoh()
<br>&gt;
<br>&gt;
<br>&gt;
<br>&gt;
<br>&gt; Perhaps we should try to make them readable. htons and ntohs are b=
ad
<br>&gt; examples to follow
<br>&gt; in that regard.
<br>&gt;
<br>
<br>+1 for readability.
<br>
<br></blockquote><div><br></div><div>99% of the time I agree. However I do =
view these kinds of bit/byte operations as primitives, also even the same a=
s operators like +, |, &lt;&lt;, etc..</div><div>These kinds of things are =
the only place I'd prefer short names to avoid typing, especially if they a=
re being combined in an expression.&nbsp;</div><div>&nbsp;</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">I also suggest to rename the bswap templa=
te to 'byte_swap' or even=20
<br>'swap_bytes'.
<br></blockquote><div>Usually for function names, I prefer verbs to go firs=
t. So swap_bytes would be preferrable. I'm not totally opposed to bswap() t=
hough for reasons mentioned above.</div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
<br>The same holds for 'bconvert' ('byte_convert' or 'convert_bytes').
<br><br></blockquote><div>This was a bad name, now there is a new one.</div=
><div><br></div><div>Updates in git.&nbsp;</div><div><br></div><div>&nbsp;<=
/div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_145_11442410.1380990875114--

.

On sexta-feira, 4 de outubro de 2013 14:51:45, Markus Mayer wrote:
> > constexpr uint16_t bswap(uint16_t v) {
> >
> >   return __builtin_bswap16(v);
> >
> > }
>
> I didn't know that __builtin_bswap could be used as a constexpr. Awesome!

Depends on the compiler.

According to comments on the Qt source code, GCC allows it but Clang doesn't.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

fmatthew5876@gmail.com skrev 2013-10-05 15:14:
>
>
> On Saturday, October 5, 2013 8:50:16 AM UTC-4, Bjorn Reese wrote:
>
>     On 10/05/2013 05:54 AM, fmatth...@gmail.com <javascript:> wrote:
>
>      > New version of header on github.
>
>     I suggest that you rename the cpu_to_* and *_to_cpu functions, because
>     not all operating systems (e.g. Stratus VOS) use the same endianness as
>     the CPU.
>
>
> I can agree with that. I've changed the name to host for the moment.
> Still open to possibly using native or some other name.

If we are going to be this picky, 'host' is not that good when you run
in a virtual environment. Neither is 'native'.  :-)


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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_82_22411378.1380995571227
Content-Type: text/plain; charset=ISO-8859-1



> If we are going to be this picky, 'host' is not that good when you run
> in a virtual environment. Neither is 'native'.  :-)
>
> Maybe true, but a little too pedantic I think as you hinted.

I like host because it also matches the networking context.
host_to_net(T t) will be symmetrical with the other byte order methods.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_82_22411378.1380995571227
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">If we are=
 going to be this picky, 'host' is not that good when you run=20
<br>in a virtual environment. Neither is 'native'. &nbsp;:-)
<br><br></blockquote><div>Maybe true, but a little too pedantic I think as =
you hinted.</div><div><br></div><div>I like host because it also matches th=
e networking context.</div><div>host_to_net(T t) will be symmetrical with t=
he other byte order methods.&nbsp;</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_82_22411378.1380995571227--

.

On 10/05/2013 05:54 AM, fmatthew5876@gmail.com wrote:
>
> Maybe this?
> enum class endian {
>    little,
>    big,
>    native = little
> };
>

Yes. I like your solution. We should just be consistent if we use the
wording 'endian' or 'byte_order' (I prefer the later, which you also use
at your version at github)

>
>     I personally would prefer the wording 'native' to 'cpu'.
>     I would move the byte_orders to template arguments (either as addition,
>     or as a replacement of the above):
>
>
> host is also another possibility. Naming is hard, lets think more, we
> have time.
>

I will create a list of possible names with some pros and cons to help
the discussion.

>
> Never heard of that, but if its possible there can be separate int and
> float endian enums like we have above.
> I don't think that adds very much complexity. In the meantime, we should
> have them in.

A quick look at wikipedia revels the following:
'However, on modern standard computers (i.e., implementing IEEE 754),
one may in practice safely assume that the endianness is the same for
floating point numbers as for integers, making the conversion
straightforward regardless of data type. (Small embedded systems using
special floating point formats may be another matter however.)'

I am not sure if we should cover that case, but my solution would look
something like:

enum class byte_order {
   little,
   big,
   integral_native = little, //Implementation defined
   floating_point_native
};

>
>
>      > //Optional: Byte Swapping an arbitrary sized buffer? Is this at
>     all useful?
>
>     I am not sure about this either. At least all supported integral types
>     should be supported.
>

After further think about it, I cann't come up with a use case requiring
a buffer swap routine.

>     Note: For buffers std::reverse_copy could be used to realize bswap.
>
>      > //Optional: Do we need/want a macro interface?
>
>     I think we you have it!

I am not that sure anymore if we really need a macro interface.

>
>     What I've been missing is a function the convert the byte_order without
>     knowing the order during compilation time. e.g:
>
>     template<typename T>
>     constexpr T convertByteOrderRT(T t, byte_order from, byte_order to);
>
>     byte_order from = ??; // Is set during runtime
>
>     uint16_t x = convertByteOrderRT(v, from, little_endian);
>
>     This function could also replace the 'convertByteOrder' function
>     mentioned above.
>
>
> runtime control makes sense.
>
>

I think we could unify the 'reorder_bytes' functions as well as the
'host_to' function to something like:

template <typename T>
constexpr T reorder_bytes(T t, byte_order in, byte_order out =
byte_order::host) {
   return in == out ? t : swap_bytes(t);
}


We also should come up with some concrete use-cases the see if we cover
them.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Markus Mayer wrote 2013-10-06 13:37:
>
> A quick look at wikipedia revels the following:
> 'However, on modern standard computers (i.e., implementing IEEE 754),
> one may in practice safely assume that the endianness is the same for
> floating point numbers as for integers, making the conversion
> straightforward regardless of data type. (Small embedded systems using
> special floating point formats may be another matter however.)'
>
> I am not sure if we should cover that case,

Another "modern" computer that doesn't use IEEE floating point by
default is IBM mainframes (zSeries).

That's a rather important platform that a language standard shouldn't
neglect.


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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On domingo, 6 de outubro de 2013 13:37:48, Markus Mayer wrote:
> >      > //Optional: Byte Swapping an arbitrary sized buffer? Is this at
> >     all useful?
> >
> >     I am not sure about this either. At least all supported integral types
> >     should be supported.
>
> After further think about it, I cann't come up with a use case requiring
> a buffer swap routine.

Here's one: checking the endianness and converting to an integral at once,
from a char buffer.

  const char *buffer = getBufferPointer();
  unsigned id = qFromBigEndian<uint16_t>(buffer);
  unsigned qdcount = qFromBigEndian<uint16_t>(buffer + 4);
  unsigned ancount = qFromBigEndian<uint16_t>(buffer + 6);
  unsigned nscount = qFromBigEndian<uint16_t>(buffer + 8);
  unsigned arcount = qFromBigEndian<uint16_t>(buffer + 10);

This is very useful when parsing binary network protocols or binary files.
Usually, the formats align the fields naturally, but sometimes they don't.
What's more, there's no guarantee that the alignment requirements of the local
CPU match those of the format. And, of course, there's the matter of whether
the character buffer was aligned enough to begin with.

See
http://code.woboq.org/qt5/qtbase/src/corelib/global/qendian.h.html#_Z14qFromBigEndianPKh

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_2396_26034244.1381084457561
Content-Type: text/plain; charset=ISO-8859-1



On Sunday, October 6, 2013 7:37:48 AM UTC-4, Markus Mayer wrote:
>
> On 10/05/2013 05:54 AM, fmatth...@gmail.com <javascript:> wrote:
> >
> > Maybe this?
> > enum class endian {
> >    little,
> >    big,
> >    native = little
> > };
> >
>
> Yes. I like your solution. We should just be consistent if we use the
> wording 'endian' or 'byte_order' (I prefer the later, which you also use
> at your version at github)
>

I also prefer byte_order.

>
> >
> >     I personally would prefer the wording 'native' to 'cpu'.
> >     I would move the byte_orders to template arguments (either as
> addition,
> >     or as a replacement of the above):
> >
> >
> > host is also another possibility. Naming is hard, lets think more, we
> > have time.
> >
>
> I will create a list of possible names with some pros and cons to help
> the discussion.
>
> >
> > Never heard of that, but if its possible there can be separate int and
> > float endian enums like we have above.
> > I don't think that adds very much complexity. In the meantime, we should
> > have them in.
>
> A quick look at wikipedia revels the following:
> 'However, on modern standard computers (i.e., implementing IEEE 754),
> one may in practice safely assume that the endianness is the same for
> floating point numbers as for integers, making the conversion
> straightforward regardless of data type. (Small embedded systems using
> special floating point formats may be another matter however.)'
>
> I am not sure if we should cover that case, but my solution would look
> something like:
>
> enum class byte_order {
>    little,
>    big,
>    integral_native = little, //Implementation defined
>    floating_point_native
> };
>

Or maybe something like this:

enum class endian {
  little,
  big
};

template <typename T>
struct byte_order<T> {
  endian value = little;
}

And then provide specializations for integral and floating point types as
needed.

The the host_to_le method becomes:
template <typename T>
T host_to_le(T t) { return byte_order<T>::value == endian::little ? t :
swap_bytes(t); }


>
> >
> >
> >      > //Optional: Byte Swapping an arbitrary sized buffer? Is this at
> >     all useful?
> >
> >     I am not sure about this either. At least all supported integral
> types
> >     should be supported.
> >
>
> After further think about it, I cann't come up with a use case requiring
> a buffer swap routine.
>
Me either, lets drop it.


>
> >     Note: For buffers std::reverse_copy could be used to realize bswap.
> >
> >      > //Optional: Do we need/want a macro interface?
> >
> >     I think we you have it!
>
> I am not that sure anymore if we really need a macro interface.
>

I am going to hold onto the macro interface. Macros might be evil, but
there could be a use for it. After all we still don't have a static_if. One
a real proposal is drafted, if the standards committee decides not to have
the macro interface, I'll remove it then.


>
> >
> >     What I've been missing is a function the convert the byte_order
> without
> >     knowing the order during compilation time. e.g:
> >
> >     template<typename T>
> >     constexpr T convertByteOrderRT(T t, byte_order from, byte_order to);
> >
> >     byte_order from = ??; // Is set during runtime
> >
> >     uint16_t x = convertByteOrderRT(v, from, little_endian);
> >
> >     This function could also replace the 'convertByteOrder' function
> >     mentioned above.
> >
> >
> > runtime control makes sense.
> >
> >
>
> I think we could unify the 'reorder_bytes' functions as well as the
> 'host_to' function to something like:
>
> template <typename T>
> constexpr T reorder_bytes(T t, byte_order in, byte_order out =
> byte_order::host) {
>    return in == out ? t : swap_bytes(t);
> }
>
>  I had some ideas like this too.

>
> We also should come up with some concrete use-cases the see if we cover
> them.
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_2396_26034244.1381084457561
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, October 6, 2013 7:37:48 AM UTC-4, Marku=
s Mayer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10/05/2013 05=
:54 AM, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
kQWzb443ouYJ">fmatth...@gmail.com</a> wrote:
<br>&gt;
<br>&gt; Maybe this?
<br>&gt; enum class endian {
<br>&gt; &nbsp; &nbsp;little,
<br>&gt; &nbsp; &nbsp;big,
<br>&gt; &nbsp; &nbsp;native =3D little
<br>&gt; };
<br>&gt;
<br>
<br>Yes. I like your solution. We should just be consistent if we use the=
=20
<br>wording 'endian' or 'byte_order' (I prefer the later, which you also us=
e=20
<br>at your version at github)
<br></blockquote><div><br></div><div>I also prefer byte_order.&nbsp;</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt;
<br>&gt; &nbsp; &nbsp; I personally would prefer the wording 'native' to 'c=
pu'.
<br>&gt; &nbsp; &nbsp; I would move the byte_orders to template arguments (=
either as addition,
<br>&gt; &nbsp; &nbsp; or as a replacement of the above):
<br>&gt;
<br>&gt;
<br>&gt; host is also another possibility. Naming is hard, lets think more,=
 we
<br>&gt; have time.
<br>&gt;
<br>
<br>I will create a list of possible names with some pros and cons to help=
=20
<br>the discussion.
<br>
<br>&gt;
<br>&gt; Never heard of that, but if its possible there can be separate int=
 and
<br>&gt; float endian enums like we have above.
<br>&gt; I don't think that adds very much complexity. In the meantime, we =
should
<br>&gt; have them in.
<br>
<br>A quick look at wikipedia revels the following:
<br>'However, on modern standard computers (i.e., implementing IEEE 754),=
=20
<br>one may in practice safely assume that the endianness is the same for=
=20
<br>floating point numbers as for integers, making the conversion=20
<br>straightforward regardless of data type. (Small embedded systems using=
=20
<br>special floating point formats may be another matter however.)'
<br>
<br>I am not sure if we should cover that case, but my solution would look=
=20
<br>something like:
<br>
<br>enum class byte_order {
<br>&nbsp; &nbsp;little,
<br>&nbsp; &nbsp;big,
<br>&nbsp; &nbsp;integral_native =3D little, //Implementation defined
<br>&nbsp; &nbsp;floating_point_native
<br>};
<br></blockquote><div><br></div><div>Or maybe something like this:</div><di=
v><br></div><div>enum class endian {</div><div>&nbsp; little,</div><div>&nb=
sp; big<br>};</div><div><br></div><div>template &lt;typename T&gt;</div><di=
v>struct byte_order&lt;T&gt; {<br>&nbsp; endian value =3D little;</div><div=
>}</div><div><br></div><div>And then provide specializations for integral a=
nd floating point types as needed.</div><div><br></div><div>The the host_to=
_le method becomes:</div><div>template &lt;typename T&gt;</div><div>T host_=
to_le(T t) { return byte_order&lt;T&gt;::value =3D=3D endian::little ? t : =
swap_bytes(t);&nbsp;}</div><div>&nbsp;</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">
<br>&gt;
<br>&gt;
<br>&gt; &nbsp; &nbsp; &nbsp;&gt; //Optional: Byte Swapping an arbitrary si=
zed buffer? Is this at
<br>&gt; &nbsp; &nbsp; all useful?
<br>&gt;
<br>&gt; &nbsp; &nbsp; I am not sure about this either. At least all suppor=
ted integral types
<br>&gt; &nbsp; &nbsp; should be supported.
<br>&gt;
<br>
<br>After further think about it, I cann't come up with a use case requirin=
g=20
<br>a buffer swap routine.
<br></blockquote><div>Me either, lets drop it.</div><div>&nbsp;</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; &nbsp; &nbsp; Note: For buffers std::reverse_copy could be used to=
 realize bswap.
<br>&gt;
<br>&gt; &nbsp; &nbsp; &nbsp;&gt; //Optional: Do we need/want a macro inter=
face?
<br>&gt;
<br>&gt; &nbsp; &nbsp; I think we you have it!
<br>
<br>I am not that sure anymore if we really need a macro interface.
<br></blockquote><div><br></div><div>I am going to hold onto the macro inte=
rface. Macros might be evil, but there could be a use for it. After all we =
still don't have a static_if. One a real proposal is drafted, if the standa=
rds committee decides not to have the macro interface, I'll remove it then.=
</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt;
<br>&gt; &nbsp; &nbsp; What I've been missing is a function the convert the=
 byte_order without
<br>&gt; &nbsp; &nbsp; knowing the order during compilation time. e.g:
<br>&gt;
<br>&gt; &nbsp; &nbsp; template&lt;typename T&gt;
<br>&gt; &nbsp; &nbsp; constexpr T convertByteOrderRT(T t, byte_order from,=
 byte_order to);
<br>&gt;
<br>&gt; &nbsp; &nbsp; byte_order from =3D ??; // Is set during runtime
<br>&gt;
<br>&gt; &nbsp; &nbsp; uint16_t x =3D convertByteOrderRT(v, from, little_en=
dian);
<br>&gt;
<br>&gt; &nbsp; &nbsp; This function could also replace the 'convertByteOrd=
er' function
<br>&gt; &nbsp; &nbsp; mentioned above.
<br>&gt;
<br>&gt;
<br>&gt; runtime control makes sense.
<br>&gt;
<br>&gt;
<br>
<br>I think we could unify the 'reorder_bytes' functions as well as the=20
<br>'host_to' function to something like:
<br>
<br>template &lt;typename T&gt;
<br>constexpr T reorder_bytes(T t, byte_order in, byte_order out =3D=20
<br>byte_order::host) {
<br>&nbsp; &nbsp;return in =3D=3D out ? t : swap_bytes(t);
<br>}
<br>
<br></blockquote><div>&nbsp;I had some ideas like this too.</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">
<br>We also should come up with some concrete use-cases the see if we cover=
=20
<br>them.
<br>
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2396_26034244.1381084457561--

.

On domingo, 6 de outubro de 2013 11:34:17, fmatthew5876@gmail.com wrote:
> template <typename T>
> struct byte_order<T> {
>   endian value = little;
> }
>
> And then provide specializations for integral and floating point types as
> needed.

Any chance of modifying numeric_limits for this?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_2395_4133066.1381086951940
Content-Type: text/plain; charset=ISO-8859-1

On Sunday, October 6, 2013 2:53:10 PM UTC-4, Thiago Macieira wrote:

> On domingo, 6 de outubro de 2013 11:34:17, fmatth...@gmail.com<javascript:>wrote:
> > template <typename T>
> > struct byte_order<T> {
> >   endian value = little;
> > }
> >
> > And then provide specializations for integral and floating point types
> as
> > needed.
>
> Any chance of modifying numeric_limits for this?
>
>
What would be the benefit of putting it there?

Keeping it as a separate trait makes it easier to extend for user defined
types like simd registers.
Also, not modifying already existing headers makes this proposal much
easier to accept.

Still if theres a compelling reason to put it in numeric_limits, we should
fight for that.


> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_2395_4133066.1381086951940
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, October 6, 2013 2:53:10 PM UTC-4, Thiago Maciei=
ra wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On domingo, 6 de =
outubro de 2013 11:34:17, <a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"mNT_agOaEQUJ">fmatth...@gmail.com</a> wrote:
<br>&gt; template &lt;typename T&gt;
<br>&gt; struct byte_order&lt;T&gt; {
<br>&gt; &nbsp; endian value =3D little;
<br>&gt; }
<br>&gt;=20
<br>&gt; And then provide specializations for integral and floating point t=
ypes as=20
<br>&gt; needed.
<br>
<br>Any chance of modifying numeric_limits for this?
<br>
<br></blockquote><div><br></div><div>What would be the benefit of putting i=
t there?</div><div><br></div><div>Keeping it as a separate trait makes it e=
asier to extend for user defined types like simd registers.</div><div>Also,=
 not modifying already existing headers makes this proposal much easier to =
accept.</div><div><br></div><div>Still if theres a compelling reason to put=
 it in numeric_limits, we should fight for that.</div><div>&nbsp;</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2395_4133066.1381086951940--

.

--001a11c2c2ca55e59c04e828d49e
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Oct 4, 2013 at 5:51 AM, Markus Mayer <lotharlutz@gmx.de> wrote:

> On 10/04/2013 07:05 AM, fmatthew5876@gmail.com wrote:
>
>>
>>     It's not standardized because networking didn't need the generic
>>     solution and I don't recall
>>     seeing a proposal for the generic one.
>>
>>
>> In that case I'd like to work on making one. Its a pretty small thing so
>> it should not be difficult.
>> Here is an example of what it might look like:
>> https://github.com/**fmatthew5876/stdcxx/blob/**master/byteorder/include/
>> **byteorder.hh<https://github.com/fmatthew5876/stdcxx/blob/master/byteorder/include/byteorder.hh>
>>
>> Anyone care to comment or add suggestions?
>>
>> Thanks!
>>
>> --
>>
>> ---
>> 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<std-proposals%2Bunsubscribe@isocpp.org>
>> .
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/**isocpp.org/group/std-**proposals/<http://groups.google.com/a/isocpp.org/group/std-proposals/>
>> .
>>
>
> Thanks for your interest in making a proposal. As I am interested in this
> topic too, I want to help you with this.
>
>  struct byte_order {
>>   enum order {
>>     little_endian = 1234,
>>     big_endian = 4321,
>>     //Optional: pdp endian? Linux defines this.
>>     pdp_endian = 3412,
>>   };
>>   constexpr static order value = little_endian; //Implementation defined
>> value little_endian or big_endian.
>> };
>>
>
> Is there a reason for these specific numbers (e.g. little_endian = 1234)?
> Using smaller numbers (0,1,...) would enable us to store the values in a
> smaller data type (e.g. char).
>
> Intentionally I would write the above as:
>
> enum class byte_order
> //enum class byte_order : unsigned char (if size matters)
> {
>     little_endian = 0,
>     big_endian = 1,
>     native_endian = little_endian //Implementation defined
> };
>
> I cannot say if it is betters or worse. What is your opinion about it?
>
>  constexpr uint16_t bswap(uint16_t v) {
>>   return __builtin_bswap16(v);
>> }
>>
>
> I didn't know that __builtin_bswap could be used as a constexpr. Awesome!
>
>  constexpr uint16_t bswap16(uint16_t t) { return bswap(t); }
>>
>
> I would prefer a template for bswap:
> template <typename T>
> constexpr T bswap(T x); //Only specialized for supported types
>

This seems problematic, because it's hard to rigorously specify "byte
swapping" for types beyond the exact-width integer types, and it may not
even be implementable with defined behavior (e.g. if byte-swapping a
well-formed value produces a trap value). It's also too low-level an API
for general use, because it requires the user to know or condition on the
host endianness, which is almost always a mistake (q.v.
http://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html).

It seems to me that what's really wanted are two symmetric operations,
serialization and deserialization, which convert between the (unspecified)
native format and an explicitly-specified byte format (e.g. 32-bit
little-endian two's complement, or big-endian IEEE 754 double-precision).
The non-native format should be handled using char*, the
standard-sanctioned way to work with uninterpreted bytes (or perhaps some
type that wraps char*).

Straw-man proposal: establish a BinaryFormatPolicy concept, such that if P
is a type that models that concept, and c is a char* value,

Policy::native_type Policy::read(c);

reads Policy::number_of_bytes bytes starting at c, and returns the value
they represent. Similarly, if v is a value of type Policy::native_type

Policy::write(v, c);

writes the encoded value of v in the Policy::number_of_bytes bytes starting
at c. You could even conceivably support variable-length encodings, by
having read and write update their pointer parameters, but then you have to
worry about issues like buffer allocation.

You'd also want to standardize at least some basic policy classes, covering
big and little endian versions of unsigned and two's complement integers in
various sizes, and IEEE single, double, and extended precision. I'm not
sure exactly how to name them; it's tempting to make things like endianness
and size be template parameters, but it's not clear how useful that is in
practice, and I worry making size a parameter will tempt users into doing
subtly wrong things like std::big_endian_ieee<sizeof(double)> in the name
of portability.


> This enables the following usages:
> uint16_t x = bswap<uint16_t>(5);
> uint16_t y = bswap(x);
>
>  template <typename T>
>> constexpr T cpu_to_le(T t) { return byte_order::value ==
>> byte_order::little_endian ? t : bswap(t); }
>>
>
> I personally would prefer the wording 'native' to 'cpu'.
> I would move the byte_orders to template arguments (either as addition, or
> as a replacement of the above):
>
> template <byte_order from, byte_order to, typename T>
> constexpr T convertByteOrder(T t);
>
>  //Optional: Should we support signed integers as well?
>>
>
> IMHO yes!
>
>  //Optional: Should we support floating point types? Do binary formats or
>> hardware devices need this?
>>
>
> Yes, I am sure someone will someday create a format that needs this (If it
> is not already existing).
>
> Question: Is there any architecture where integers and floating point
> numbers are stored in different endianesses?
>

As was pointed out elsewhere in the thread, the answer is yes, and worse,
Wikipedia refers to "old ARM processors that have half little-endian, half
big-endian floating point representation". The possibility of boustraphedon
endianness even for integers has already come up. However, per the above,
we shouldn't have to care about any possible host endianness- we just need
to care about the formats for which it's worth standardizing the ability to
read and write them.


>
>  //Optional: Byte Swapping an arbitrary sized buffer? Is this at all
>> useful?
>>
>
> I am not sure about this either. At least all supported integral types
> should be supported.
>
> Note: For buffers std::reverse_copy could be used to realize bswap.
>
>  //Optional: Do we need/want a macro interface?
>>
>
> I think we you have it!
>
> What I've been missing is a function the convert the byte_order without
> knowing the order during compilation time. e.g:
>
> template<typename T>
> constexpr T convertByteOrderRT(T t, byte_order from, byte_order to);
>
> byte_order from = ??; // Is set during runtime
>
> uint16_t x = convertByteOrderRT(v, from, little_endian);
>
> This function could also replace the 'convertByteOrder' function mentioned
> above.
>
> Some corner cases we probably should not care about:
> - Swapping of types with sizes like 6 Byte
> - Behavior when CHAR_BITS != 8
>
>
> I hope these remarks are helpful for you and welcome any feedback.
>
>
> regards, Markus
>
>
>
>
>
>
>
>
>
>
> --
>
> --- 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<std-proposals%2Bunsubscribe@isocpp.org>
> .
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/**isocpp.org/group/std-**
> proposals/ <http://groups.google.com/a/isocpp.org/group/std-proposals/>.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c2c2ca55e59c04e828d49e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Fri, Oct 4, 2013 at 5:51 AM, Markus Mayer <span dir=3D"ltr">&lt;<a href=
=3D"mailto:lotharlutz@gmx.de" target=3D"_blank">lotharlutz@gmx.de</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D""><div class=3D"h5">On 10/04/2013 07:05 AM, =
<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@gm=
ail.com</a> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<br>
=A0 =A0 It&#39;s not standardized because networking didn&#39;t need the ge=
neric<br>
=A0 =A0 solution and I don&#39;t recall<br>
=A0 =A0 seeing a proposal for the generic one.<br>
<br>
<br>
In that case I&#39;d like to work on making one. Its a pretty small thing s=
o<br>
it should not be difficult.<br>
Here is an example of what it might look like:<br>
<a href=3D"https://github.com/fmatthew5876/stdcxx/blob/master/byteorder/inc=
lude/byteorder.hh" target=3D"_blank">https://github.com/<u></u>fmatthew5876=
/stdcxx/blob/<u></u>master/byteorder/include/<u></u>byteorder.hh</a><br>
<br>
Anyone care to comment or add suggestions?<br>
<br>
Thanks!<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google<br>
Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send<br>
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" targe=
t=3D"_blank">std-proposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at<br>
<a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/" targ=
et=3D"_blank">http://groups.google.com/a/<u></u>isocpp.org/group/std-<u></u=
>proposals/</a>.<br>
</blockquote>
<br></div></div>
Thanks for your interest in making a proposal. As I am interested in this t=
opic too, I want to help you with this.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
struct byte_order {<br>
=A0 enum order {<br>
=A0 =A0 little_endian =3D 1234,<br>
=A0 =A0 big_endian =3D 4321,<br>
=A0 =A0 //Optional: pdp endian? Linux defines this.<br>
=A0 =A0 pdp_endian =3D 3412,<br>
=A0 };<br>
=A0 constexpr static order value =3D little_endian; //Implementation define=
d value little_endian or big_endian.<br>
};<br>
</blockquote>
<br>
Is there a reason for these specific numbers (e.g. little_endian =3D 1234)?=
 Using smaller numbers (0,1,...) would enable us to store the values in a s=
maller data type (e.g. char).<br>
<br>
Intentionally I would write the above as:<br>
<br>
enum class byte_order<br>
//enum class byte_order : unsigned char (if size matters)<br>
{<br>
=A0 =A0 little_endian =3D 0,<br>
=A0 =A0 big_endian =3D 1,<br>
=A0 =A0 native_endian =3D little_endian //Implementation defined<br>
};<br>
<br>
I cannot say if it is betters or worse. What is your opinion about it?<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
constexpr uint16_t bswap(uint16_t v) {<br>
=A0 return __builtin_bswap16(v);<br>
}<br>
</blockquote>
<br>
I didn&#39;t know that __builtin_bswap could be used as a constexpr. Awesom=
e!<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
constexpr uint16_t bswap16(uint16_t t) { return bswap(t); }<br>
</blockquote>
<br>
I would prefer a template for bswap:<br>
template &lt;typename T&gt;<br>
constexpr T bswap(T x); //Only specialized for supported types<br></blockqu=
ote><div><br></div><div>This seems problematic, because it&#39;s hard to ri=
gorously specify &quot;byte swapping&quot; for types beyond the exact-width=
 integer types, and it may not even be implementable with defined behavior =
(e.g. if byte-swapping a well-formed value produces a trap value). It&#39;s=
 also too low-level an API for general use, because it requires the user to=
 know or condition on the host endianness, which is almost always a mistake=
 (q.v.=A0<a href=3D"http://commandcenter.blogspot.com/2012/04/byte-order-fa=
llacy.html">http://commandcenter.blogspot.com/2012/04/byte-order-fallacy.ht=
ml</a>).</div>
<div><br></div><div>It seems to me that what&#39;s really wanted are two sy=
mmetric operations, serialization and deserialization, which convert betwee=
n the (unspecified) native format and an explicitly-specified byte format (=
e.g. 32-bit little-endian two&#39;s complement, or big-endian IEEE 754 doub=
le-precision). The non-native format should be handled using char*, the sta=
ndard-sanctioned way to work with uninterpreted bytes (or perhaps some type=
 that wraps char*). <br>
<br>Straw-man proposal: establish a BinaryFormatPolicy concept, such that i=
f P is a type that models that concept, and c is a char* value,</div><div><=
br></div><div>Policy::native_type Policy::read(c);</div><div><br></div>
<div>reads Policy::number_of_bytes bytes starting at c, and returns the val=
ue they represent. Similarly, if v is a value of type Policy::native_type</=
div><div><br></div><div>Policy::write(v, c);</div><div><br></div><div>write=
s the encoded value of v in the Policy::number_of_bytes bytes starting at c=
.. You could even conceivably support variable-length encodings, by having r=
ead and write update their pointer parameters, but then you have to worry a=
bout issues like buffer allocation.</div>
<div><br></div><div>You&#39;d also want to standardize at least some basic =
policy classes, covering big and little endian versions of unsigned and two=
&#39;s complement integers in various sizes, and IEEE single, double, and e=
xtended precision. I&#39;m not sure exactly how to name them; it&#39;s temp=
ting to make things like endianness and size be template parameters, but it=
&#39;s not clear how useful that is in practice, and I worry making size a =
parameter will tempt users into doing subtly wrong things like std::big_end=
ian_ieee&lt;sizeof(double)&gt; in the name of portability.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">
<br>
This enables the following usages:<br>
uint16_t x =3D bswap&lt;uint16_t&gt;(5);<br>
uint16_t y =3D bswap(x);<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
template &lt;typename T&gt;<br>
constexpr T cpu_to_le(T t) { return byte_order::value =3D=3D byte_order::li=
ttle_endian ? t : bswap(t); }<br>
</blockquote>
<br>
I personally would prefer the wording &#39;native&#39; to &#39;cpu&#39;.<br=
>
I would move the byte_orders to template arguments (either as addition, or =
as a replacement of the above):<br>
<br>
template &lt;byte_order from, byte_order to, typename T&gt;<br>
constexpr T convertByteOrder(T t);<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
//Optional: Should we support signed integers as well?<br>
</blockquote>
<br>
IMHO yes!<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
//Optional: Should we support floating point types? Do binary formats or ha=
rdware devices need this?<br>
</blockquote>
<br>
Yes, I am sure someone will someday create a format that needs this (If it =
is not already existing).<br>
<br>
Question: Is there any architecture where integers and floating point numbe=
rs are stored in different endianesses?<br></blockquote><div><br></div><div=
>As was pointed out elsewhere in the thread, the answer is yes, and worse, =
Wikipedia refers to &quot;old ARM processors that have half little-endian, =
half big-endian floating point representation&quot;. The possibility of bou=
straphedon endianness even for integers has already come up. However, per t=
he above, we shouldn&#39;t have to care about any possible host endianness-=
 we just need to care about the formats for which it&#39;s worth standardiz=
ing the ability to read and write them.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
//Optional: Byte Swapping an arbitrary sized buffer? Is this at all useful?=
<br>
</blockquote>
<br>
I am not sure about this either. At least all supported integral types shou=
ld be supported.<br>
<br>
Note: For buffers std::reverse_copy could be used to realize bswap.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
//Optional: Do we need/want a macro interface?<br>
</blockquote>
<br>
I think we you have it!<br>
<br>
What I&#39;ve been missing is a function the convert the byte_order without=
 knowing the order during compilation time. e.g:<br>
<br>
template&lt;typename T&gt;<br>
constexpr T convertByteOrderRT(T t, byte_order from, byte_order to);<br>
<br>
byte_order from =3D ??; // Is set during runtime<br>
<br>
uint16_t x =3D convertByteOrderRT(v, from, little_endian);<br>
<br>
This function could also replace the &#39;convertByteOrder&#39; function me=
ntioned above.<br>
<br>
Some corner cases we probably should not care about:<br>
- Swapping of types with sizes like 6 Byte<br>
- Behavior when CHAR_BITS !=3D 8<br>
<br>
<br>
I hope these remarks are helpful for you and welcome any feedback.<br>
<br>
<br>
regards, Markus<div class=3D""><div class=3D"h5"><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &quot;ISO C++ Standard - Future Proposals&quot; 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@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2c2ca55e59c04e828d49e--

.

------=_Part_1687_27850521.1381279270594
Content-Type: text/plain; charset=ISO-8859-1



On Monday, October 7, 2013 12:06:05 PM UTC-4, Geoffrey Romer wrote:
>
>
> On Fri, Oct 4, 2013 at 5:51 AM, Markus Mayer <lotha...@gmx.de<javascript:>
> > wrote:
>
>> On 10/04/2013 07:05 AM, fmatth...@gmail.com <javascript:> wrote:
>>
>>>
>>>     It's not standardized because networking didn't need the generic
>>>     solution and I don't recall
>>>     seeing a proposal for the generic one.
>>>
>>>
>>> In that case I'd like to work on making one. Its a pretty small thing so
>>> it should not be difficult.
>>> Here is an example of what it might look like:
>>> https://github.com/**fmatthew5876/stdcxx/blob/**
>>> master/byteorder/include/**byteorder.hh<https://github.com/fmatthew5876/stdcxx/blob/master/byteorder/include/byteorder.hh>
>>>
>>> Anyone care to comment or add suggestions?
>>>
>>> Thanks!
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@**isocpp.org <javascript:>.
>>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>>> Visit this group at
>>> http://groups.google.com/a/**isocpp.org/group/std-**proposals/<http://groups.google.com/a/isocpp.org/group/std-proposals/>
>>> .
>>>
>>
>> Thanks for your interest in making a proposal. As I am interested in this
>> topic too, I want to help you with this.
>>
>>  struct byte_order {
>>>   enum order {
>>>     little_endian = 1234,
>>>     big_endian = 4321,
>>>     //Optional: pdp endian? Linux defines this.
>>>     pdp_endian = 3412,
>>>   };
>>>   constexpr static order value = little_endian; //Implementation defined
>>> value little_endian or big_endian.
>>> };
>>>
>>
>> Is there a reason for these specific numbers (e.g. little_endian = 1234)?
>> Using smaller numbers (0,1,...) would enable us to store the values in a
>> smaller data type (e.g. char).
>>
>> Intentionally I would write the above as:
>>
>> enum class byte_order
>> //enum class byte_order : unsigned char (if size matters)
>> {
>>     little_endian = 0,
>>     big_endian = 1,
>>     native_endian = little_endian //Implementation defined
>> };
>>
>> I cannot say if it is betters or worse. What is your opinion about it?
>>
>>  constexpr uint16_t bswap(uint16_t v) {
>>>   return __builtin_bswap16(v);
>>> }
>>>
>>
>> I didn't know that __builtin_bswap could be used as a constexpr. Awesome!
>>
>>  constexpr uint16_t bswap16(uint16_t t) { return bswap(t); }
>>>
>>
>> I would prefer a template for bswap:
>> template <typename T>
>> constexpr T bswap(T x); //Only specialized for supported types
>>
>
> This seems problematic, because it's hard to rigorously specify "byte
> swapping" for types beyond the exact-width integer types, and it may not
> even be implementable with defined behavior (e.g. if byte-swapping a
> well-formed value produces a trap value). It's also too
>

Even if byte-swapping performs a trap value (for example, signalling nan
for float), all it does is store the value in either a register or memory.
Is there any architecture where merely storing a particular bit pattern
could cause a fault or exception? I certainly would hope not.
If your byteswapped value could cause an exception by doing other
operations arithmetic on it, that's ok.


> low-level an API for general use, because it requires the user to know or
> condition on the host endianness, which is almost always a mistake (q.v.
> http://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html).
>
Thank you for this, the the point of view made from this article was very
enlightening. I'll comment more at the end.

>
> It seems to me that what's really wanted are two symmetric operations,
> serialization and deserialization, which convert between the (unspecified)
> native format and an explicitly-specified byte format (e.g. 32-bit
> little-endian two's complement, or big-endian IEEE 754 double-precision).
> The non-native format should be handled using char*, the
> standard-sanctioned way to work with uninterpreted bytes (or perhaps some
> type that wraps char*).
>

Yes converting from whatever native is to big and little endian is really
the end goal. The byte order of the machine is an implementation detail.

>
> Straw-man proposal: establish a BinaryFormatPolicy concept, such that if P
> is a type that models that concept, and c is a char* value,
>
> Policy::native_type Policy::read(c);
>
Isn't this pointer requirement a bit restrictive? File Io in particular
does not expose it's internal buffer.

float farray[512];
read_from_file(somefile, farray, sizeof(farray));

//Entire loop should be optimized out if host is big endian.
for(auto& f : farray) {
f = be_to_host(f);
}


> reads Policy::number_of_bytes bytes starting at c, and returns the value
> they represent. Similarly, if v is a value of type Policy::native_type
>
> Policy::write(v, c);
>
> writes the encoded value of v in the Policy::number_of_bytes bytes
> starting at c. You could even conceivably support variable-length
> encodings, by having read and write update their pointer parameters, but
> then you have to worry about issues like buffer allocation.
>
> You'd also want to standardize at least some basic policy classes,
> covering big and little endian versions of unsigned and two's complement
> integers in various sizes, and IEEE single, double, and extended precision.
> I'm not sure exactly how to name them; it's tempting to make things like
> endianness and size be template parameters, but it's not clear how useful
> that is in practice, and I worry making size a parameter will tempt users
> into doing subtly wrong things like std::big_endian_ieee<sizeof(double)> in
> the name of portability.
>
>
>> This enables the following usages:
>> uint16_t x = bswap<uint16_t>(5);
>> uint16_t y = bswap(x);
>>
>>  template <typename T>
>>> constexpr T cpu_to_le(T t) { return byte_order::value ==
>>> byte_order::little_endian ? t : bswap(t); }
>>>
>>
>> I personally would prefer the wording 'native' to 'cpu'.
>> I would move the byte_orders to template arguments (either as addition,
>> or as a replacement of the above):
>>
>> template <byte_order from, byte_order to, typename T>
>> constexpr T convertByteOrder(T t);
>>
>>  //Optional: Should we support signed integers as well?
>>>
>>
>> IMHO yes!
>>
>>  //Optional: Should we support floating point types? Do binary formats or
>>> hardware devices need this?
>>>
>>
>> Yes, I am sure someone will someday create a format that needs this (If
>> it is not already existing).
>>
>> Question: Is there any architecture where integers and floating point
>> numbers are stored in different endianesses?
>>
>
> As was pointed out elsewhere in the thread, the answer is yes, and worse,
> Wikipedia refers to "old ARM processors that have half little-endian, half
> big-endian floating point representation". The possibility of boustraphedon
> endianness even for integers has already come up. However, per the above,
> we shouldn't have to care about any possible host endianness- we just need
> to care about the formats for which it's worth standardizing the ability to
> read and write them.
>
>
>>
>>  //Optional: Byte Swapping an arbitrary sized buffer? Is this at all
>>> useful?
>>>
>>
>> I am not sure about this either. At least all supported integral types
>> should be supported.
>>
>> Note: For buffers std::reverse_copy could be used to realize bswap.
>>
>>  //Optional: Do we need/want a macro interface?
>>>
>>
>> I think we you have it!
>>
>> What I've been missing is a function the convert the byte_order without
>> knowing the order during compilation time. e.g:
>>
>> template<typename T>
>> constexpr T convertByteOrderRT(T t, byte_order from, byte_order to);
>>
>> byte_order from = ??; // Is set during runtime
>>
>> uint16_t x = convertByteOrderRT(v, from, little_endian);
>>
>> This function could also replace the 'convertByteOrder' function
>> mentioned above.
>>
>> Some corner cases we probably should not care about:
>> - Swapping of types with sizes like 6 Byte
>> - Behavior when CHAR_BITS != 8
>>
>>
>> I hope these remarks are helpful for you and welcome any feedback.
>>
>>
>> regards, Markus
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> --- You received this message because you are subscribed to the Google
>> Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@**isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at http://groups.google.com/a/**isocpp.org/group/std-**
>> proposals/ <http://groups.google.com/a/isocpp.org/group/std-proposals/>.
>>
>
> I'll have to consider your policy idea a bit more first. Something like
that could be a better interface.

This brings up an interesting question. Do we actually need to expose the
host byte order at all?
If we just provide host_to_Xe() functions, then we avoid all of these nasty
corner cases with strange byte orders.

In addition, exposing the byte order also brings problems when a new
architecture with some byte order not in the standard list is presented.
User code that is written this way will break;
if(host_byte_order == little_endian) {
  //Do little endian stuff
}  else {
  //Assume big endian
}

This becomes impossible if there is no exposed host byte order.

So now let me ask this question. If we just provide host_to_Xe() methods
for all builtin types (and optionally encourage overloads for
implementation specific types like simd as needed),
is there ever a case where users will still need a method of determining
the system byte order?

Put another way, is it possible for us to account for all possible uses
cases of knowing the byte order and just provide those via a simple
interface?
The only time I've ever needed it is for serialization.

If exposing the byte order enables an important use case that cannot be
abstracted, then I'd be inclined to keep it around. Otherwise, do we really
need it at all?




--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1687_27850521.1381279270594
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, October 7, 2013 12:06:05 PM UTC-4, Geof=
frey Romer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><br><div><div class=3D"gmail_quote">On Fri, Oct 4, 2013 at 5:51 AM, Mar=
kus Mayer <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"h2Tbcupxb1EJ">lotha...@gmx.de</a>&gt;</span> wrote:=
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div><div>On 10/04/2013 07:05 AM, <a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"h2Tbcupxb1EJ">fmatth...@gmail.co=
m</a> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<br>
&nbsp; &nbsp; It's not standardized because networking didn't need the gene=
ric<br>
&nbsp; &nbsp; solution and I don't recall<br>
&nbsp; &nbsp; seeing a proposal for the generic one.<br>
<br>
<br>
In that case I'd like to work on making one. Its a pretty small thing so<br=
>
it should not be difficult.<br>
Here is an example of what it might look like:<br>
<a href=3D"https://github.com/fmatthew5876/stdcxx/blob/master/byteorder/inc=
lude/byteorder.hh" target=3D"_blank">https://github.com/<u></u>fmatthew587<=
wbr>6/stdcxx/blob/<u></u>master/<wbr>byteorder/include/<u></u>byteorder.hh<=
/a><br>
<br>
Anyone care to comment or add suggestions?<br>
<br>
Thanks!<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google<br>
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send<br>
an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"h2Tbcupxb1EJ">std-proposal...@<u></u>isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"h2Tbcupxb1EJ">std-pr...@isocpp.org</a>.<br>
Visit this group at<br>
<a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/" targ=
et=3D"_blank">http://groups.google.com/a/<u></u>iso<wbr>cpp.org/group/std-<=
u></u>proposals/</a>.<br>
</blockquote>
<br></div></div>
Thanks for your interest in making a proposal. As I am interested in this t=
opic too, I want to help you with this.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
struct byte_order {<br>
&nbsp; enum order {<br>
&nbsp; &nbsp; little_endian =3D 1234,<br>
&nbsp; &nbsp; big_endian =3D 4321,<br>
&nbsp; &nbsp; //Optional: pdp endian? Linux defines this.<br>
&nbsp; &nbsp; pdp_endian =3D 3412,<br>
&nbsp; };<br>
&nbsp; constexpr static order value =3D little_endian; //Implementation def=
ined value little_endian or big_endian.<br>
};<br>
</blockquote>
<br>
Is there a reason for these specific numbers (e.g. little_endian =3D 1234)?=
 Using smaller numbers (0,1,...) would enable us to store the values in a s=
maller data type (e.g. char).<br>
<br>
Intentionally I would write the above as:<br>
<br>
enum class byte_order<br>
//enum class byte_order : unsigned char (if size matters)<br>
{<br>
&nbsp; &nbsp; little_endian =3D 0,<br>
&nbsp; &nbsp; big_endian =3D 1,<br>
&nbsp; &nbsp; native_endian =3D little_endian //Implementation defined<br>
};<br>
<br>
I cannot say if it is betters or worse. What is your opinion about it?<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
constexpr uint16_t bswap(uint16_t v) {<br>
&nbsp; return __builtin_bswap16(v);<br>
}<br>
</blockquote>
<br>
I didn't know that __builtin_bswap could be used as a constexpr. Awesome!<b=
r>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
constexpr uint16_t bswap16(uint16_t t) { return bswap(t); }<br>
</blockquote>
<br>
I would prefer a template for bswap:<br>
template &lt;typename T&gt;<br>
constexpr T bswap(T x); //Only specialized for supported types<br></blockqu=
ote><div><br></div><div>This seems problematic, because it's hard to rigoro=
usly specify "byte swapping" for types beyond the exact-width integer types=
, and it may not even be implementable with defined behavior (e.g. if byte-=
swapping a well-formed value produces a trap value). It's also too </div></=
div></div></div></blockquote><div><br></div><div>Even if byte-swapping perf=
orms a trap value (for example, signalling nan for float), all it does is s=
tore the value in either a register or memory. Is there any architecture wh=
ere merely storing a particular bit pattern could cause a fault or exceptio=
n? I certainly would hope not.</div><div>If your byteswapped value could ca=
use an exception by doing other operations arithmetic on it, that's ok.</di=
v><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote"><div>low-level an API for general use=
, because it requires the user to know or condition on the host endianness,=
 which is almost always a mistake (q.v.&nbsp;<a href=3D"http://commandcente=
r.blogspot.com/2012/04/byte-order-fallacy.html" target=3D"_blank">http://co=
mmandcenter.<wbr>blogspot.com/2012/04/byte-<wbr>order-fallacy.html</a>).</d=
iv></div></div></div></blockquote><div>Thank you for this, the the point of=
 view made from this article was very enlightening. I'll comment more at th=
e end.&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div class=3D"gmail_quote">
<div><br></div><div>It seems to me that what's really wanted are two symmet=
ric operations, serialization and deserialization, which convert between th=
e (unspecified) native format and an explicitly-specified byte format (e.g.=
 32-bit little-endian two's complement, or big-endian IEEE 754 double-preci=
sion). The non-native format should be handled using char*, the standard-sa=
nctioned way to work with uninterpreted bytes (or perhaps some type that wr=
aps char*). <br></div></div></div></div></blockquote><div><br></div><div>Ye=
s converting from whatever native is to big and little endian is really the=
 end goal. The byte order of the machine is an implementation detail.&nbsp;=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote"><div>
<br>Straw-man proposal: establish a BinaryFormatPolicy concept, such that i=
f P is a type that models that concept, and c is a char* value,</div><div><=
br></div><div>Policy::native_type Policy::read(c);</div></div></div></div><=
/blockquote><div>Isn't this pointer requirement a bit restrictive? File Io =
in particular does not expose it's internal buffer.</div><div><br></div><di=
v>float farray[512];</div><div>read_from_file(somefile, farray, sizeof(farr=
ay));</div><div><br></div><div>//Entire loop should be optimized out if hos=
t is big endian.</div><div>for(auto&amp; f : farray) {<br>f =3D be_to_host(=
f);</div><div>}</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div>
<div>reads Policy::number_of_bytes bytes starting at c, and returns the val=
ue they represent. Similarly, if v is a value of type Policy::native_type</=
div><div><br></div><div>Policy::write(v, c);</div><div><br></div><div>write=
s the encoded value of v in the Policy::number_of_bytes bytes starting at c=
.. You could even conceivably support variable-length encodings, by having r=
ead and write update their pointer parameters, but then you have to worry a=
bout issues like buffer allocation.</div>
<div><br></div><div>You'd also want to standardize at least some basic poli=
cy classes, covering big and little endian versions of unsigned and two's c=
omplement integers in various sizes, and IEEE single, double, and extended =
precision. I'm not sure exactly how to name them; it's tempting to make thi=
ngs like endianness and size be template parameters, but it's not clear how=
 useful that is in practice, and I worry making size a parameter will tempt=
 users into doing subtly wrong things like std::big_endian_ieee&lt;sizeof(<=
wbr>double)&gt; in the name of portability.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">
<br>
This enables the following usages:<br>
uint16_t x =3D bswap&lt;uint16_t&gt;(5);<br>
uint16_t y =3D bswap(x);<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
template &lt;typename T&gt;<br>
constexpr T cpu_to_le(T t) { return byte_order::value =3D=3D byte_order::li=
ttle_endian ? t : bswap(t); }<br>
</blockquote>
<br>
I personally would prefer the wording 'native' to 'cpu'.<br>
I would move the byte_orders to template arguments (either as addition, or =
as a replacement of the above):<br>
<br>
template &lt;byte_order from, byte_order to, typename T&gt;<br>
constexpr T convertByteOrder(T t);<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
//Optional: Should we support signed integers as well?<br>
</blockquote>
<br>
IMHO yes!<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
//Optional: Should we support floating point types? Do binary formats or ha=
rdware devices need this?<br>
</blockquote>
<br>
Yes, I am sure someone will someday create a format that needs this (If it =
is not already existing).<br>
<br>
Question: Is there any architecture where integers and floating point numbe=
rs are stored in different endianesses?<br></blockquote><div><br></div><div=
>As was pointed out elsewhere in the thread, the answer is yes, and worse, =
Wikipedia refers to "old ARM processors that have half little-endian, half =
big-endian floating point representation". The possibility of boustraphedon=
 endianness even for integers has already come up. However, per the above, =
we shouldn't have to care about any possible host endianness- we just need =
to care about the formats for which it's worth standardizing the ability to=
 read and write them.</div>
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
//Optional: Byte Swapping an arbitrary sized buffer? Is this at all useful?=
<br>
</blockquote>
<br>
I am not sure about this either. At least all supported integral types shou=
ld be supported.<br>
<br>
Note: For buffers std::reverse_copy could be used to realize bswap.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
//Optional: Do we need/want a macro interface?<br>
</blockquote>
<br>
I think we you have it!<br>
<br>
What I've been missing is a function the convert the byte_order without kno=
wing the order during compilation time. e.g:<br>
<br>
template&lt;typename T&gt;<br>
constexpr T convertByteOrderRT(T t, byte_order from, byte_order to);<br>
<br>
byte_order from =3D ??; // Is set during runtime<br>
<br>
uint16_t x =3D convertByteOrderRT(v, from, little_endian);<br>
<br>
This function could also replace the 'convertByteOrder' function mentioned =
above.<br>
<br>
Some corner cases we probably should not care about:<br>
- Swapping of types with sizes like 6 Byte<br>
- Behavior when CHAR_BITS !=3D 8<br>
<br>
<br>
I hope these remarks are helpful for you and welcome any feedback.<br>
<br>
<br>
regards, Markus<div><div><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
h2Tbcupxb1EJ">std-proposal...@<u></u>isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"h2Tbcupxb1EJ">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>iso<wbr=
>cpp.org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></blockquote><div>I'll have =
to consider your policy idea a bit more first. Something like that could be=
 a better interface.</div><div><br></div><div>This brings up an interesting=
 question. Do we actually need to expose the host byte order at all?</div><=
div>If we just provide host_to_Xe() functions, then we avoid all of these n=
asty corner cases with strange byte orders.</div><div><br></div><div>In add=
ition, exposing the byte order also brings problems when a new architecture=
 with some byte order not in the standard list is presented.</div><div>User=
 code that is written this way will break;</div><div>if(host_byte_order =3D=
=3D little_endian) {<br>&nbsp; //Do little endian stuff</div><div>} &nbsp;e=
lse {<br>&nbsp; //Assume big endian</div><div>}</div><div><br></div><div>Th=
is becomes impossible if there is no exposed host byte order.</div><div><br=
></div><div>So now let me ask this question. If we just provide host_to_Xe(=
) methods for all builtin types (and optionally encourage overloads for imp=
lementation specific types like simd as needed),</div><div>is there ever a =
case where users will still need a method of determining the system byte or=
der?</div><div><br></div><div>Put another way, is it possible for us to acc=
ount for all possible uses cases of knowing the byte order and just provide=
 those via a simple interface?</div><div>The only time I've ever needed it =
is for serialization.</div><div><br></div><div>If exposing the byte order e=
nables an important use case that cannot be abstracted, then I'd be incline=
d to keep it around. Otherwise, do we really need it at all?</div><div><br>=
</div><div><br></div><div>&nbsp;</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1687_27850521.1381279270594--

.

------=_Part_999_430730.1381279282846
Content-Type: text/plain; charset=ISO-8859-1

There are situations in which you want to do more than just host vs.
specified. For instance, you may have a machine that translates from one
networking protocol to another. On the receiving end, the data is in
little-endian format, but on the sending end, the data must be in
big-endian format. You don't want to have to go through any intermediate
step, you just want to convert little to big, even if you happen to be
running on a PDP-10.

For what it's worth, both I and Beman Dawes have worked on two fairly
complete endian libraries (that are partially merged). Mine only has the
byte conversion functions, and his also has integer types of specified
endianness. I will let Beman discuss his version (if he reads this), but
mine can be found at https://bitbucket.org/davidstone/endian so this might
be a good reference for discussion. I believe that is should work on any
platform with a standard-compliant implementation, even if CHAR_BIT == 19,
sizeof(short) == sizeof(int) == sizeof(long) == (sizeof(long long) / 9).

Based on my experiences now, I would actually argue against the naming
decisions that I made in that library. For reference, the functions are
named in the style of `T be_to_le(T t)` and `T h_to_pdp(T t)`. My original
guide was to follow the lead of htons-style function. The type is never
included in the function name, though, and possible values in either
position are be, le, pdp, h, and n. I now believe that it would be better
to depart a bit from these somewhat cryptic names. This functions are
unlikely to be called very often (usually relegated to one or two locations
as part of a larger library function), and will almost never be part of
large chained expressions. Typical use would likely look something like

    int const value = n_to_h(read_int(socket));

as the most complicated form in most code. I believe that this justifies a
more verbose naming convention with less abbreviation, and were I to
re-write this library, I would spell things out more. My preference would
be a name like host_to_network or little_to_big. host_to_network_byte_order
is getting a little too long. I also don't feel like we get any benefit
from specifying the source and destination formats as an enum passed via
template parameter.

Whether the "network" version of byte ordering functions is needed at all
is something we would have to decide as well. I lean toward leaving it out
(and just having people use "big"), but I do not feel strongly about this
and would not complain if others preferred to have it in. I do not know how
languages other than C name similar functions.

"host" would be my preferred name over "native" or "cpu", but this also
isn't an important issue to me.

Theoretically these could be defined as constexpr using the new relaxed
constexpr rules (but not as I defined the functions due to the use of
reinterpret_cast). However, this would constrain implementations a bit.
Based on my testing, the reinterpret_cast version actually ended up being
slower on all compilers, but it is also the only simple solution that works
for floating point types. Moreover, most uses of an endian library will be
for writing to files or network interfaces, which cannot be done in
constexpr functions, anyway, so these functions probably should not be
declared constexpr.

They also should not be declared noexcept due to the possibility of trap
representations.



Given all of this, I don't believe it would be necessary to worry about
defining some sort of enum or integer value to specify what the byte order
of the host machine is, as the only purpose for such a thing that I can see
would be to define these functions.



There are systems where the data segment of memory can be little or big
endian, and on such systems, these functions should still work as expected
(do a dynamic determination of what type of system it is).

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_999_430730.1381279282846
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There are situations in which you want to do more than jus=
t host vs. specified. For instance, you may have a machine that translates =
from one networking protocol to another. On the receiving end, the data is =
in little-endian format, but on the sending end, the data must be in big-en=
dian format. You don't want to have to go through any intermediate step, yo=
u just want to convert little to big, even if you happen to be running on a=
 PDP-10.<br><br>For what it's worth, both I and Beman Dawes have worked on =
two fairly complete endian libraries (that are partially merged). Mine only=
 has the byte conversion functions, and his also has integer types of speci=
fied endianness. I will let Beman discuss his version (if he reads this), b=
ut mine can be found at https://bitbucket.org/davidstone/endian so this mig=
ht be a good reference for discussion. I believe that is should work on any=
 platform with a standard-compliant implementation, even if CHAR_BIT =3D=3D=
 19, sizeof(short) =3D=3D sizeof(int) =3D=3D sizeof(long) =3D=3D (sizeof(lo=
ng long) / 9).<br><br>Based on my experiences now, I would actually argue a=
gainst the naming decisions that I made in that library. For reference, the=
 functions are named in the style of `T be_to_le(T t)` and `T h_to_pdp(T t)=
`. My original guide was to follow the lead of htons-style function. The ty=
pe is never included in the function name, though, and possible values in e=
ither position are be, le, pdp, h, and n. I now believe that it would be be=
tter to depart a bit from these somewhat cryptic names. This functions are =
unlikely to be called very often (usually relegated to one or two locations=
 as part of a larger library function), and will almost never be part of la=
rge chained expressions. Typical use would likely look something like<br><b=
r>&nbsp;&nbsp;&nbsp; int const value =3D n_to_h(read_int(socket));<br><br>a=
s the most complicated form in most code. I believe that this justifies a m=
ore verbose naming convention with less abbreviation, and were I to re-writ=
e this library, I would spell things out more. My preference would be a nam=
e like host_to_network or little_to_big. host_to_network_byte_order is gett=
ing a little too long. I also don't feel like we get any benefit from speci=
fying the source and destination formats as an enum passed via template par=
ameter.<br><br>Whether the "network" version of byte ordering functions is =
needed at all is something we would have to decide as well. I  lean toward =
leaving it out (and just having people use "big"), but I do not feel strong=
ly about this and would not complain if others preferred to have it in. I d=
o not know how languages other than C name similar functions.<br><br>"host"=
 would be my preferred name over "native" or "cpu", but this also isn't an =
important issue to me.<br><br>Theoretically these could be defined as const=
expr using the new relaxed constexpr rules (but not as I defined the functi=
ons due to the use of reinterpret_cast). However, this would constrain impl=
ementations a bit. Based on my testing, the reinterpret_cast version actual=
ly ended up being slower on all compilers, but it is also the only simple s=
olution that works for floating point types. Moreover, most uses of an endi=
an library will be for writing to files or network interfaces, which cannot=
 be done in constexpr functions, anyway, so these functions probably should=
 not be declared constexpr.<br><br>They also should not be declared noexcep=
t due to the possibility of trap representations.<br><br><br><br>Given all =
of this, I don't believe it would be necessary to worry about defining some=
 sort of enum or integer value to specify what the byte order of the host m=
achine is, as the only purpose for such a thing that I can see would be to =
define these functions.<br><br><br><br>There are systems where the data seg=
ment of memory can be little or big endian, and on such systems, these func=
tions should still work as expected (do a dynamic determination of what typ=
e of system it is).<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_999_430730.1381279282846--

.

------=_Part_1699_28602526.1381287490023
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, October 8, 2013 8:41:22 PM UTC-4, David Stone wrote:
>
> There are situations in which you want to do more than just host vs.
> specified. For instance, you may have a machine that translates from one
> networking protocol to another. On the receiving end, the data is in
> little-endian format, but on the sending end, the data must be in
> big-endian format. You don't want to have to go through any intermediate
> step, you just want to convert little to big, even if you happen to be
> running on a PDP-10.
>

Indeed, we should have conversions to and from the different formats. This
is useful for virtual machines, binary converters, and such.


>
> For what it's worth, both I and Beman Dawes have worked on two fairly
> complete endian libraries (that are partially merged). Mine only has the
> byte conversion functions, and his also has integer types of specified
> endianness. I will let Beman discuss his version (if he
>

Please contact him and let him know about this if you can. I'd really like
the input of people who have already done this before. Experience is the
most valuable teacher.


> reads this), but mine can be found at
> https://bitbucket.org/davidstone/endian so this might be a good reference
> for discussion.
>
Very cool, I will take a look.


> I believe that is should work on any platform with a standard-compliant
> implementation, even if CHAR_BIT == 19, sizeof(short) == sizeof(int) ==
> sizeof(long) == (sizeof(long long) / 9).
>

> Based on my experiences now, I would actually argue against the naming
> decisions that I made in that library. For reference, the functions are
> named in the style of `T be_to_le(T t)` and `T h_to_pdp(T t)`. My original
> guide was to follow the lead of htons-style function. The type is never
> included in the function name, though, and possible values in either
> position are be, le, pdp, h, and n. I now believe that it would be better
> to depart a bit from these somewhat cryptic names. This functions are
> unlikely to be called very often (usually relegated to one or two locations
> as part of a larger library function), and will almost never be part of
> large chained expressions. Typical use would likely look something like
>
>     int const value = n_to_h(read_int(socket));
>
> as the most complicated form in most code. I believe that this justifies a
> more verbose naming convention with less abbreviation, and were I to
> re-write this library, I would spell things out more. My preference would
> be a name like host_to_network or little_to_big. host_to_network_byte_order
> is getting a little too long.
>

That's good to know. Naming is always the hardest thing to decide.


> I also don't feel like we get any benefit from specifying the source and
> destination formats as an enum passed via template parameter.
>

Perhaps you want to write a customizable serialization class/framework and
pass in the byte order of target byte stream? Providing templated versions
certainly doesn't hurt.


> Whether the "network" version of byte ordering functions is needed at all
> is something we would have to decide as well. I lean toward leaving it out
> (and just having people use "big"), but I do not feel strongly about this
> and would not complain if others preferred to have it in. I do not know how
> languages other than C name similar functions.
>

Actually we don't. I'm going to leave this to the networking people to
decide for themselves.
One thing we may want to collaborate on is naming. If we use
host_to_little, they may want to do host_to_network, if we to htole or
host_to_le, maybe they stick with hton.


>
> "host" would be my preferred name over "native" or "cpu", but this also
> isn't an important issue to me.
>

I'm kind of in favor of host as well. It at least matches the traditional
networking context everyone is familiar with.


>
> Theoretically these could be defined as constexpr using the new relaxed
> constexpr rules (but not as I defined the functions due to the use of
> reinterpret_cast). However, this would constrain implementations a bit.
> Based on my testing, the reinterpret_cast version actually ended up being
> slower on all compilers, but it is also the only simple solution that works
> for floating point types. Moreover, most uses of an endian library will be
> for writing to files or network interfaces, which cannot be done in
> constexpr functions, anyway, so these functions probably should not be
> declared constexpr.
>

I'm strongly in favor of constexpr. You can define things like constant
headers or hardware device ordinals right into your code with no runtime
overhead.

struct header {
  uint32_t version,
  uint32_t size,
};
const header hdr = {
host_to_be(5),
host_to_be(32)
};

write(file, hdr, sizeof(hdr));
write(file, data, 32);

Also, it wouldn't surprise me if constexpr continues to get more powerful
and permissive as time goes on.


> They also should not be declared noexcept due to the possibility of trap
> representations.
>
> This was mentioned before.
Do you know of a concrete example on some machine?

>
>
> Given all of this, I don't believe it would be necessary to worry about
> defining some sort of enum or integer value to specify what the byte order
> of the host machine is, as the only purpose for such a thing that I can see
> would be to define these functions.
>
> I think so too. Unless someone can come up with a compelling use case,
maybe it should be left undefined.

>
>
> There are systems where the data segment of memory can be little or big
> endian, and on such systems, these functions should still work as expected
> (do a dynamic determination of what type of system it is).
>

This is another possible issue. What are the limits of configurable byte
orders? If its just that the app can be compiled one way or the other, then
its no problem. If it has to be determined at runtime, that would break
constexpr.


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1699_28602526.1381287490023
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, October 8, 2013 8:41:22 PM UTC-4, Davi=
d Stone wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>There are situations in which you want to do more than just host vs. speci=
fied. For instance, you may have a machine that translates from one network=
ing protocol to another. On the receiving end, the data is in little-endian=
 format, but on the sending end, the data must be in big-endian format. You=
 don't want to have to go through any intermediate step, you just want to c=
onvert little to big, even if you happen to be running on a PDP-10.<br></di=
v></blockquote><div><br></div><div>Indeed, we should have conversions to an=
d from the different formats. This is useful for virtual machines, binary c=
onverters, and such.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div dir=3D"ltr"><br>For what it's worth, both I and Beman Daw=
es have worked on two fairly complete endian libraries (that are partially =
merged). Mine only has the byte conversion functions, and his also has inte=
ger types of specified endianness. I will let Beman discuss his version (if=
 he </div></blockquote><div><br></div><div>Please contact him and let him k=
now about this if you can. I'd really like the input of people who have alr=
eady done this before. Experience is the most valuable teacher.</div><div>&=
nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">re=
ads this), but mine can be found at <a href=3D"https://bitbucket.org/davids=
tone/endian" target=3D"_blank">https://bitbucket.org/<wbr>davidstone/endian=
</a> so this might be a good reference for discussion. </div></blockquote><=
div>Very cool, I will take a look.</div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">I believe that is should work =
on any platform with a standard-compliant implementation, even if CHAR_BIT =
=3D=3D 19, sizeof(short) =3D=3D sizeof(int) =3D=3D sizeof(long) =3D=3D (siz=
eof(long long) / 9).&nbsp;</div></blockquote><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><br>Based on my experiences now, I would ac=
tually argue against the naming decisions that I made in that library. For =
reference, the functions are named in the style of `T be_to_le(T t)` and `T=
 h_to_pdp(T t)`. My original guide was to follow the lead of htons-style fu=
nction. The type is never included in the function name, though, and possib=
le values in either position are be, le, pdp, h, and n. I now believe that =
it would be better to depart a bit from these somewhat cryptic names. This =
functions are unlikely to be called very often (usually relegated to one or=
 two locations as part of a larger library function), and will almost never=
 be part of large chained expressions. Typical use would likely look someth=
ing like<br><br>&nbsp;&nbsp;&nbsp; int const value =3D n_to_h(read_int(sock=
et));<br><br>as the most complicated form in most code. I believe that this=
 justifies a more verbose naming convention with less abbreviation, and wer=
e I to re-write this library, I would spell things out more. My preference =
would be a name like host_to_network or little_to_big. host_to_network_byte=
_order is getting a little too long. </div></blockquote><div><br></div><div=
>That's good to know. Naming is always the hardest thing to decide.</div><d=
iv>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">I also don't feel like we get any benefit from specifying the source and =
destination formats as an enum passed via template parameter.<br></div></bl=
ockquote><div>&nbsp;</div><div>Perhaps you want to write a customizable ser=
ialization class/framework and pass in the byte order of target byte stream=
? Providing templated versions certainly doesn't hurt.</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br>Whether t=
he "network" version of byte ordering functions is needed at all is somethi=
ng we would have to decide as well. I  lean toward leaving it out (and just=
 having people use "big"), but I do not feel strongly about this and would =
not complain if others preferred to have it in. I do not know how languages=
 other than C name similar functions.<br></div></blockquote><div><br></div>=
<div>Actually we don't. I'm going to leave this to the networking people to=
 decide for themselves.</div><div>One thing we may want to collaborate on i=
s naming. If we use host_to_little, they may want to do host_to_network, if=
 we to htole or host_to_le, maybe they stick with hton.</div><div>&nbsp;</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br>"host"=
 would be my preferred name over "native" or "cpu", but this also isn't an =
important issue to me.<br></div></blockquote><div><br></div><div>I'm kind o=
f in favor of host as well. It at least matches the traditional networking =
context everyone is familiar with.</div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><br>Theoretically these could =
be defined as constexpr using the new relaxed constexpr rules (but not as I=
 defined the functions due to the use of reinterpret_cast). However, this w=
ould constrain implementations a bit. Based on my testing, the reinterpret_=
cast version actually ended up being slower on all compilers, but it is als=
o the only simple solution that works for floating point types. Moreover, m=
ost uses of an endian library will be for writing to files or network inter=
faces, which cannot be done in constexpr functions, anyway, so these functi=
ons probably should not be declared constexpr.<br></div></blockquote><div><=
br></div><div>I'm strongly in favor of constexpr. You can define things lik=
e constant headers or hardware device ordinals right into your code with no=
 runtime overhead.</div><div><br></div><div>struct header {</div><div>&nbsp=
; uint32_t version,</div><div>&nbsp; uint32_t size,</div><div>};</div><div>=
const header hdr =3D {</div><div>host_to_be(5),</div><div>host_to_be(32)</d=
iv><div>};</div><div><br></div><div>write(file, hdr, sizeof(hdr));</div><di=
v>write(file, data, 32);</div><div><br></div><div>Also, it wouldn't surpris=
e me if constexpr continues to get more powerful and permissive as time goe=
s on.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr"><br>They also should not be declared noexcept due to the possi=
bility of trap representations.<br><br></div></blockquote><div>This was men=
tioned before.&nbsp;</div><div>Do you know of a concrete example on some ma=
chine?</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
br><br>Given all of this, I don't believe it would be necessary to worry ab=
out defining some sort of enum or integer value to specify what the byte or=
der of the host machine is, as the only purpose for such a thing that I can=
 see would be to define these functions.<br><br></div></blockquote><div>I t=
hink so too. Unless someone can come up with a compelling use case, maybe i=
t should be left undefined.</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><br><br>There are systems where the data segment of mem=
ory can be little or big endian, and on such systems, these functions shoul=
d still work as expected (do a dynamic determination of what type of system=
 it is).<br></div></blockquote><div><br></div><div>This is another possible=
 issue. What are the limits of configurable byte orders? If its just that t=
he app can be compiled one way or the other, then its no problem. If it has=
 to be determined at runtime, that would break constexpr.</div><div>&nbsp;<=
/div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1699_28602526.1381287490023--

.

------=_Part_1041_11544386.1381288627223
Content-Type: text/plain; charset=ISO-8859-1

Another possible naming convention that someone had brought up in the past
is that for "host" configurations, the "host" can simply be implied. Rather
than host_to_big, the function would be to_big. Rather than little_to_host
the function would be from_little. However, that was in the context of a
proposed boost::endian namespace. Perhaps this library should follow the
lead of std::chrono with the use of a nested namespace?

Consider the case of the some ARM processors:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0278b/Cegbbbab.html .
The endianness can be set dynamically by setting a global signal, and that
endianness can be big, little, or "mixed", which is the same as little
endian, except that 64-bit values have their 32-bit "words" swapped (which
is similar to how PDP-endianness is with 16-bit vs. 32-bit values).

This type of scenario appears to ruin any possibility of constexpr support
in general.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1041_11544386.1381288627223
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Another possible naming convention that someone had brough=
t up in the past is that for "host" configurations, the "host" can simply b=
e implied. Rather than host_to_big, the function would be to_big. Rather th=
an little_to_host the function would be from_little. However, that was in t=
he context of a proposed boost::endian namespace. Perhaps this library shou=
ld follow the lead of std::chrono with the use of a nested namespace?<br><b=
r>Consider the case of the some ARM processors: http://infocenter.arm.com/h=
elp/topic/com.arm.doc.ddi0278b/Cegbbbab.html . The endianness can be set dy=
namically by setting a global signal, and that endianness can be big, littl=
e, or "mixed", which is the same as little endian, except that 64-bit value=
s have their 32-bit "words" swapped (which is similar to how PDP-endianness=
 is with 16-bit vs. 32-bit values).<br><br>This type of scenario appears to=
 ruin any possibility of constexpr support in general.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1041_11544386.1381288627223--

.

------=_Part_1605_32149468.1381289997021
Content-Type: text/plain; charset=ISO-8859-1

As for trap representations, this is trivial if we allow the endian
functions to work on floating point values for systems with IEEE floats.
There are valid values for double in one endianness that would be a
signaling NaN on another. I don't know off-hand of any real platforms that
have trap representations for integer types, but I would be suspicious of
getting the -0 representation on a one's complement or sign-magnitude
architecture.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1605_32149468.1381289997021
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As for trap representations, this is trivial if we allow t=
he endian functions to work on floating point values for systems with IEEE =
floats. There are valid values for double in one endianness that would be a=
 signaling NaN on another. I don't know off-hand of any real platforms that=
 have trap representations for integer types, but I would be suspicious of =
getting the -0 representation on a one's complement or sign-magnitude archi=
tecture.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1605_32149468.1381289997021--

.

On 10/06/2013 08:32 PM, Thiago Macieira wrote:
> On domingo, 6 de outubro de 2013 13:37:48, Markus Mayer wrote:
>>>       > //Optional: Byte Swapping an arbitrary sized buffer? Is this at
>>>      all useful?
>>>
>>>      I am not sure about this either. At least all supported integral types
>>>      should be supported.
>>
>> After further think about it, I cann't come up with a use case requiring
>> a buffer swap routine.
>
> Here's one: checking the endianness and converting to an integral at once,
> from a char buffer.
>
>    const char *buffer = getBufferPointer();
>    unsigned id = qFromBigEndian<uint16_t>(buffer);
>    unsigned qdcount = qFromBigEndian<uint16_t>(buffer + 4);
>    unsigned ancount = qFromBigEndian<uint16_t>(buffer + 6);
>    unsigned nscount = qFromBigEndian<uint16_t>(buffer + 8);
>    unsigned arcount = qFromBigEndian<uint16_t>(buffer + 10);
>
> This is very useful when parsing binary network protocols or binary files.
> Usually, the formats align the fields naturally, but sometimes they don't.
> What's more, there's no guarantee that the alignment requirements of the local
> CPU match those of the format. And, of course, there's the matter of whether
> the character buffer was aligned enough to begin with.
>
> See
> http://code.woboq.org/qt5/qtbase/src/corelib/global/qendian.h.html#_Z14qFromBigEndianPKh
>

I think this would mix two unrelated functions into one. (byte_order
conversion and obtaining values from a buffer)

The proper solution would be two independent functions like:

unsigned qdcount = big_to_host(fromBuffer<uint16_t>(buffer + 4));

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 10/06/2013 08:53 PM, Thiago Macieira wrote:
> On domingo, 6 de outubro de 2013 11:34:17, fmatthew5876@gmail.com wrote:
>> template <typename T>
>> struct byte_order<T> {
>>    endian value = little;
>> }
>>
>> And then provide specializations for integral and floating point types as
>> needed.
>
> Any chance of modifying numeric_limits for this?
>

I also thought about this, but how does the byte_order relate to the
term "numeric_limits".

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 10/09/2013 05:17 AM, David Stone wrote:
> Another possible naming convention that someone had brought up in the
> past is that for "host" configurations, the "host" can simply be
> implied. Rather than host_to_big, the function would be to_big. Rather
> than little_to_host the function would be from_little. However, that was
> in the context of a proposed boost::endian namespace. Perhaps this
> library should follow the lead of std::chrono with the use of a nested
> namespace?
>
> Consider the case of the some ARM processors:
> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0278b/Cegbbbab.html
> . The endianness can be set dynamically by setting a global signal, and
> that endianness can be big, little, or "mixed", which is the same as
> little endian, except that 64-bit values have their 32-bit "words"
> swapped (which is similar to how PDP-endianness is with 16-bit vs.
> 32-bit values).
>
> This type of scenario appears to ruin any possibility of constexpr
> support in general.

Even if you can change the endianness of some arm processors, the
compiler still needs to know the endianess (gcc uses -mlittle-endian and
-mbig-endian for arm) to correctly layout multibyte values.

>
> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On quarta-feira, 9 de outubro de 2013 17:17:03, Markus Mayer wrote:
> The proper solution would be two independent functions like:
>
> unsigned qdcount = big_to_host(fromBuffer<uint16_t>(buffer + 4));

Maybe, or that might be slower.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a11c253c02c323204e8520c66
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 8, 2013 at 5:41 PM, <fmatthew5876@gmail.com> wrote:

>
>
> On Monday, October 7, 2013 12:06:05 PM UTC-4, Geoffrey Romer wrote:
>>
>>
>> On Fri, Oct 4, 2013 at 5:51 AM, Markus Mayer <lotha...@gmx.de> wrote:
>>
>>> On 10/04/2013 07:05 AM, fmatth...@gmail.com wrote:
>>>
>>>>
>>>>     It's not standardized because networking didn't need the generic
>>>>     solution and I don't recall
>>>>     seeing a proposal for the generic one.
>>>>
>>>>
>>>> In that case I'd like to work on making one. Its a pretty small thing so
>>>> it should not be difficult.
>>>> Here is an example of what it might look like:
>>>> https://github.com/**fmatthew587**6/stdcxx/blob/**master/**
>>>> byteorder/include/**byteorder.hh<https://github.com/fmatthew5876/stdcxx/blob/master/byteorder/include/byteorder.hh>
>>>>
>>>> Anyone care to comment or add suggestions?
>>>>
>>>> Thanks!
>>>>
>>>> --
>>>>
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to std-proposal...@**isoc**pp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>
>>>> Visit this group at
>>>> http://groups.google.com/a/**iso**cpp.org/group/std-**proposals/<http://groups.google.com/a/isocpp.org/group/std-proposals/>
>>>> .
>>>>
>>>
>>> Thanks for your interest in making a proposal. As I am interested in
>>> this topic too, I want to help you with this.
>>>
>>>  struct byte_order {
>>>>   enum order {
>>>>     little_endian = 1234,
>>>>     big_endian = 4321,
>>>>     //Optional: pdp endian? Linux defines this.
>>>>     pdp_endian = 3412,
>>>>   };
>>>>   constexpr static order value = little_endian; //Implementation
>>>> defined value little_endian or big_endian.
>>>> };
>>>>
>>>
>>> Is there a reason for these specific numbers (e.g. little_endian =
>>> 1234)? Using smaller numbers (0,1,...) would enable us to store the values
>>> in a smaller data type (e.g. char).
>>>
>>> Intentionally I would write the above as:
>>>
>>> enum class byte_order
>>> //enum class byte_order : unsigned char (if size matters)
>>> {
>>>     little_endian = 0,
>>>     big_endian = 1,
>>>     native_endian = little_endian //Implementation defined
>>> };
>>>
>>> I cannot say if it is betters or worse. What is your opinion about it?
>>>
>>>  constexpr uint16_t bswap(uint16_t v) {
>>>>   return __builtin_bswap16(v);
>>>> }
>>>>
>>>
>>> I didn't know that __builtin_bswap could be used as a constexpr. Awesome!
>>>
>>>  constexpr uint16_t bswap16(uint16_t t) { return bswap(t); }
>>>>
>>>
>>> I would prefer a template for bswap:
>>> template <typename T>
>>> constexpr T bswap(T x); //Only specialized for supported types
>>>
>>
>> This seems problematic, because it's hard to rigorously specify "byte
>> swapping" for types beyond the exact-width integer types, and it may not
>> even be implementable with defined behavior (e.g. if byte-swapping a
>> well-formed value produces a trap value). It's also too
>>
>
> Even if byte-swapping performs a trap value (for example, signalling nan
> for float), all it does is store the value in either a register or memory.
> Is there any architecture where merely storing a particular bit pattern
> could cause a fault or exception? I certainly would hope not.
>
If your byteswapped value could cause an exception by doing other
> operations arithmetic on it, that's ok.
>

I'm not very familiar with how trap values work on various architectures,
so you may be right on that, but my point is more general: the whole point
of strong typing is to provide a guarantee that typed objects are
well-formed. In other words, 'float' should only be used to store
floating-point numbers; it is an abuse of the type system to use it to
store "some bytes that we will eventually convert to a floating point
number", and the standard library should not enable those sorts of abuses.
It's a bad practice, even if not technically harmful in this particular
case.

The correct type for storing uninterpreted bytes is char* (although if you
get me drunk enough, I might also endorse unsigned integral types in some
circumstances).


>
>
>> low-level an API for general use, because it requires the user to know or
>> condition on the host endianness, which is almost always a mistake (q.v.
>> http://commandcenter.**blogspot.com/2012/04/byte-**order-fallacy.html<http://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html>
>> ).
>>
> Thank you for this, the the point of view made from this article was very
> enlightening. I'll comment more at the end.
>
>>
>> It seems to me that what's really wanted are two symmetric operations,
>> serialization and deserialization, which convert between the (unspecified)
>> native format and an explicitly-specified byte format (e.g. 32-bit
>> little-endian two's complement, or big-endian IEEE 754 double-precision).
>> The non-native format should be handled using char*, the
>> standard-sanctioned way to work with uninterpreted bytes (or perhaps some
>> type that wraps char*).
>>
>
> Yes converting from whatever native is to big and little endian is really
> the end goal. The byte order of the machine is an implementation detail.
>
>>
>> Straw-man proposal: establish a BinaryFormatPolicy concept, such that if
>> P is a type that models that concept, and c is a char* value,
>>
>> Policy::native_type Policy::read(c);
>>
> Isn't this pointer requirement a bit restrictive? File Io in particular
> does not expose it's internal buffer.
>

Yes, that's one of several reasons this is only a straw man, not a real
proposal. One could imagine using some sort of generic byte-source and
byte-sink concept instead of char*, or providing overloads for iostreams.
Ideally, the API would cleanly support both I/O and in-place conversion.
It's important, though, that the optimizer be able to fully inline read(),
write(), and iteration operations on the source/sink types, so that it can
eliminate no-op loops.


>
> float farray[512];
> read_from_file(somefile, farray, sizeof(farray));
>
> //Entire loop should be optimized out if host is big endian.
> for(auto& f : farray) {
> f = be_to_host(f);
> }
>

There are two problems with this code. First of all, you are reading
uninterpreted bytes directly into float objects. As discussed above, this
is a bad practice; the behavior of this code is at best unspecified, if not
outright undefined, and I'm far from convinced it's safe in practice, given
the possibility of things like signaling NaNs.

Second, it's not portable. It tacitly assumes that sizeof(float) is exactly
equal to the size of floating point numbers in somefile's format, but this
cannot be true in general, because the standard does not uniquely determine
sizeof(float). Worse, your comment indicates that be_to_host does nothing
but byte swapping, which means that this code is also assuming that the
host uses the same floating-point format as somefile.

These are the exact points I wanted to emphasize with my proposed API:
- The conversion API must not be symmetric: the wire-format data is an
uninterpreted byte sequence, and must be treated as such by the type system.
- The conversion API cannot be parameterized by the host type: it must be
parameterized by the wire format (which contains strictly more
information). It is implementation-defined whether any given host type can
hold all possible values of a given wire format, so the host type must be
dictated by the API, not by the user.

Here's how I'd write that code (note that I've tweaked some names from my
previous proposal):

char raw_array[512 * big_endian_ieee_single::wire_size];
read_from_file(somefile, farray, sizeof(farray));

typedef big_endian_ieee_single::host_type ieee_float;
static_assert(sizeof(ieee_float) == big_endian_ieee_single::wire_size);

char* ptr = raw_array;
// Entire loop should be optimized out if host supports big-endian IEEE
while (ptr < raw_array + sizeof(raw_array)) {
  reinterpret_cast<ieee_float>(ptr) = big_endian_ieee_single::read(ptr);
  ptr += sizeof(ieee_float);
}

ieee_float* float_array = reinterpret_cast<ieee_float*>(raw_array);

Note that the static_assert is not guaranteed to succeed, but it's much
more likely to be true than if I was using "float" in place of the
ieee_float typedef. If I wanted my code to be completely portable, I'd need
to allocate the raw and deserialized arrays separately, but I could
probably use SFINAE tricks to do this only when sizeof(ieee_float)
!= big_endian_ieee_single::wire_size.


>
>> reads Policy::number_of_bytes bytes starting at c, and returns the value
>> they represent. Similarly, if v is a value of type Policy::native_type
>>
>> Policy::write(v, c);
>>
>> writes the encoded value of v in the Policy::number_of_bytes bytes
>> starting at c. You could even conceivably support variable-length
>> encodings, by having read and write update their pointer parameters, but
>> then you have to worry about issues like buffer allocation.
>>
>> You'd also want to standardize at least some basic policy classes,
>> covering big and little endian versions of unsigned and two's complement
>> integers in various sizes, and IEEE single, double, and extended precision.
>> I'm not sure exactly how to name them; it's tempting to make things like
>> endianness and size be template parameters, but it's not clear how useful
>> that is in practice, and I worry making size a parameter will tempt users
>> into doing subtly wrong things like std::big_endian_ieee<sizeof(**double)>
>> in the name of portability.
>>
>>
>>> This enables the following usages:
>>> uint16_t x = bswap<uint16_t>(5);
>>> uint16_t y = bswap(x);
>>>
>>>  template <typename T>
>>>> constexpr T cpu_to_le(T t) { return byte_order::value ==
>>>> byte_order::little_endian ? t : bswap(t); }
>>>>
>>>
>>> I personally would prefer the wording 'native' to 'cpu'.
>>> I would move the byte_orders to template arguments (either as addition,
>>> or as a replacement of the above):
>>>
>>> template <byte_order from, byte_order to, typename T>
>>> constexpr T convertByteOrder(T t);
>>>
>>>  //Optional: Should we support signed integers as well?
>>>>
>>>
>>> IMHO yes!
>>>
>>>  //Optional: Should we support floating point types? Do binary formats
>>>> or hardware devices need this?
>>>>
>>>
>>> Yes, I am sure someone will someday create a format that needs this (If
>>> it is not already existing).
>>>
>>> Question: Is there any architecture where integers and floating point
>>> numbers are stored in different endianesses?
>>>
>>
>> As was pointed out elsewhere in the thread, the answer is yes, and worse,
>> Wikipedia refers to "old ARM processors that have half little-endian, half
>> big-endian floating point representation". The possibility of boustraphedon
>> endianness even for integers has already come up. However, per the above,
>> we shouldn't have to care about any possible host endianness- we just need
>> to care about the formats for which it's worth standardizing the ability to
>> read and write them.
>>
>>
>>>
>>>  //Optional: Byte Swapping an arbitrary sized buffer? Is this at all
>>>> useful?
>>>>
>>>
>>> I am not sure about this either. At least all supported integral types
>>> should be supported.
>>>
>>> Note: For buffers std::reverse_copy could be used to realize bswap.
>>>
>>>  //Optional: Do we need/want a macro interface?
>>>>
>>>
>>> I think we you have it!
>>>
>>> What I've been missing is a function the convert the byte_order without
>>> knowing the order during compilation time. e.g:
>>>
>>> template<typename T>
>>> constexpr T convertByteOrderRT(T t, byte_order from, byte_order to);
>>>
>>> byte_order from = ??; // Is set during runtime
>>>
>>> uint16_t x = convertByteOrderRT(v, from, little_endian);
>>>
>>> This function could also replace the 'convertByteOrder' function
>>> mentioned above.
>>>
>>> Some corner cases we probably should not care about:
>>> - Swapping of types with sizes like 6 Byte
>>> - Behavior when CHAR_BITS != 8
>>>
>>>
>>> I hope these remarks are helpful for you and welcome any feedback.
>>>
>>>
>>> regards, Markus
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> --- You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@**isoc**pp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>>
>>> Visit this group at http://groups.google.com/a/**iso**cpp.org/group/std-
>>> **proposals/<http://groups.google.com/a/isocpp.org/group/std-proposals/>
>>> .
>>>
>>
>> I'll have to consider your policy idea a bit more first. Something like
> that could be a better interface.
>
> This brings up an interesting question. Do we actually need to expose the
> host byte order at all?
> If we just provide host_to_Xe() functions, then we avoid all of these
> nasty corner cases with strange byte orders.
>
> In addition, exposing the byte order also brings problems when a new
> architecture with some byte order not in the standard list is presented.
> User code that is written this way will break;
> if(host_byte_order == little_endian) {
>   //Do little endian stuff
> }  else {
>   //Assume big endian
> }
>
> This becomes impossible if there is no exposed host byte order.
>
> So now let me ask this question. If we just provide host_to_Xe() methods
> for all builtin types (and optionally encourage overloads for
> implementation specific types like simd as needed),
> is there ever a case where users will still need a method of determining
> the system byte order?
>
> Put another way, is it possible for us to account for all possible uses
> cases of knowing the byte order and just provide those via a simple
> interface?
> The only time I've ever needed it is for serialization.
>
> If exposing the byte order enables an important use case that cannot be
> abstracted, then I'd be inclined to keep it around. Otherwise, do we really
> need it at all?
>

The major case I'm aware of is, as David mentioned, when you want to
translate between two formats. Notably, even in this case you don't
actually care about the native byte order, you just want to efficiently
convert one well-specified format to another. We could extend the API with
something like

template <typename SourcePolicy, typename SinkPolicy>
void convert_byte_format(const char* source, char* sink);

which the implementation can specialize appropriately (an interesting but
solvable challenge would be to extend this to support user-defined
policies). However, that may be over-engineering; this use case seems too
marginal to warrant much standardization effort, and a separate API may not
be needed: you can just code this in terms of the to-host/from-host API

char* source, sink;
// Initialize source and sink
while (have_more_input) {
  SourcePolicy::host_type tmp = SourcePolicy::read(source);
  SourcePolicy::write(tmp, sink);
  // increment source and sink
}

and rely on the optimizer to generate efficient code. I'd expect a decent
optimizer to be able to turn this into a minimal number of byte-swaps and
copies, and to completely eliminate the loop when the source and sink have
the same endianness.

In case it wasn't clear, I don't support exposing the host byte order in a
standard API: It would be annoyingly hard to standardize such an API in the
face of mixed endianness, dynamic endianness, and other complicating
factors, and the result would likely be an "attractive nuisance" rather
than a genuinely useful utility. The people who really need it are probably
already living in the land of implementation-defined behavior, so they can
just use vendor extensions.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c253c02c323204e8520c66
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Oct 8, 2013 at 5:41 PM,  <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@gmail.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><br><br>On Monday, October 7, 2013 12:06:=
05 PM UTC-4, Geoffrey Romer wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr"><br><div><div class=3D"gmail_quote">On Fri, Oct 4, 2013 at=
 5:51 AM, Markus Mayer <span dir=3D"ltr">&lt;<a>lotha...@gmx.de</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div><div><div class=3D"im">On 10/04/2013 07:05 AM, <a>fma=
tth...@gmail.com</a> wrote:<br>


</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div class=3D"im">
<br>
=A0 =A0 It&#39;s not standardized because networking didn&#39;t need the ge=
neric<br>
=A0 =A0 solution and I don&#39;t recall<br>
=A0 =A0 seeing a proposal for the generic one.<br>
<br>
<br>
In that case I&#39;d like to work on making one. Its a pretty small thing s=
o<br>
it should not be difficult.<br>
Here is an example of what it might look like:<br>
<a href=3D"https://github.com/fmatthew5876/stdcxx/blob/master/byteorder/inc=
lude/byteorder.hh" target=3D"_blank">https://github.com/<u></u>fmatthew587<=
u></u>6/stdcxx/blob/<u></u>master/<u></u>byteorder/include/<u></u>byteorder=
..hh</a><br>

<br>
Anyone care to comment or add suggestions?<br>
<br>
Thanks!<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google<br>
Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send<br><=
/div>
an email to <a>std-proposal...@<u></u>isoc<u></u>pp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<div><div =
class=3D"h5"><br>
Visit this group at<br>
<a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/" targ=
et=3D"_blank">http://groups.google.com/a/<u></u>iso<u></u>cpp.org/group/std=
-<u></u>proposals/</a>.<br>
</div></div></blockquote>
<br></div></div><div><div class=3D"h5">
Thanks for your interest in making a proposal. As I am interested in this t=
opic too, I want to help you with this.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
struct byte_order {<br>
=A0 enum order {<br>
=A0 =A0 little_endian =3D 1234,<br>
=A0 =A0 big_endian =3D 4321,<br>
=A0 =A0 //Optional: pdp endian? Linux defines this.<br>
=A0 =A0 pdp_endian =3D 3412,<br>
=A0 };<br>
=A0 constexpr static order value =3D little_endian; //Implementation define=
d value little_endian or big_endian.<br>
};<br>
</blockquote>
<br>
Is there a reason for these specific numbers (e.g. little_endian =3D 1234)?=
 Using smaller numbers (0,1,...) would enable us to store the values in a s=
maller data type (e.g. char).<br>
<br>
Intentionally I would write the above as:<br>
<br>
enum class byte_order<br>
//enum class byte_order : unsigned char (if size matters)<br>
{<br>
=A0 =A0 little_endian =3D 0,<br>
=A0 =A0 big_endian =3D 1,<br>
=A0 =A0 native_endian =3D little_endian //Implementation defined<br>
};<br>
<br>
I cannot say if it is betters or worse. What is your opinion about it?<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
constexpr uint16_t bswap(uint16_t v) {<br>
=A0 return __builtin_bswap16(v);<br>
}<br>
</blockquote>
<br>
I didn&#39;t know that __builtin_bswap could be used as a constexpr. Awesom=
e!<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
constexpr uint16_t bswap16(uint16_t t) { return bswap(t); }<br>
</blockquote>
<br>
I would prefer a template for bswap:<br>
template &lt;typename T&gt;<br>
constexpr T bswap(T x); //Only specialized for supported types<br></div></d=
iv></blockquote><div><div class=3D"h5"><div><br></div><div>This seems probl=
ematic, because it&#39;s hard to rigorously specify &quot;byte swapping&quo=
t; for types beyond the exact-width integer types, and it may not even be i=
mplementable with defined behavior (e.g. if byte-swapping a well-formed val=
ue produces a trap value). It&#39;s also too </div>
</div></div></div></div></div></blockquote><div><br></div><div>Even if byte=
-swapping performs a trap value (for example, signalling nan for float), al=
l it does is store the value in either a register or memory. Is there any a=
rchitecture where merely storing a particular bit pattern could cause a fau=
lt or exception? I certainly would hope not.=A0</div>
</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>If your byteswapp=
ed value could cause an exception by doing other operations arithmetic on i=
t, that&#39;s ok.</div>
</div></blockquote><div><br></div><div>I&#39;m not very familiar with how t=
rap values work on various architectures, so you may be right on that, but =
my point is more general: the whole point of strong typing is to provide a =
guarantee that typed objects are well-formed. In other words, &#39;float&#3=
9; should only be used to store floating-point numbers; it is an abuse of t=
he type system to use it to store &quot;some bytes that we will eventually =
convert to a floating point number&quot;, and the standard library should n=
ot enable those sorts of abuses. It&#39;s a bad practice, even if not techn=
ically harmful in this particular case.</div>
<div><br></div><div>The correct type for storing uninterpreted bytes is cha=
r* (although if you get me drunk enough, I might also endorse unsigned inte=
gral types in some circumstances).</div><div>=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im"><div>=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr">
<div><div class=3D"gmail_quote"><div>low-level an API for general use, beca=
use it requires the user to know or condition on the host endianness, which=
 is almost always a mistake (q.v.=A0<a href=3D"http://commandcenter.blogspo=
t.com/2012/04/byte-order-fallacy.html" target=3D"_blank">http://commandcent=
er.<u></u>blogspot.com/2012/04/byte-<u></u>order-fallacy.html</a>).</div>
</div></div></div></blockquote></div><div>Thank you for this, the the point=
 of view made from this article was very enlightening. I&#39;ll comment mor=
e at the end.=A0</div><div class=3D"im"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote">
<div><br></div><div>It seems to me that what&#39;s really wanted are two sy=
mmetric operations, serialization and deserialization, which convert betwee=
n the (unspecified) native format and an explicitly-specified byte format (=
e.g. 32-bit little-endian two&#39;s complement, or big-endian IEEE 754 doub=
le-precision). The non-native format should be handled using char*, the sta=
ndard-sanctioned way to work with uninterpreted bytes (or perhaps some type=
 that wraps char*). <br>
</div></div></div></div></blockquote><div><br></div></div><div>Yes converti=
ng from whatever native is to big and little endian is really the end goal.=
 The byte order of the machine is an implementation detail.=A0</div><div cl=
ass=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>
<br>Straw-man proposal: establish a BinaryFormatPolicy concept, such that i=
f P is a type that models that concept, and c is a char* value,</div><div><=
br></div><div>Policy::native_type Policy::read(c);</div></div></div></div>
</blockquote></div><div>Isn&#39;t this pointer requirement a bit restrictiv=
e? File Io in particular does not expose it&#39;s internal buffer.=A0</div>=
</div></blockquote><div><br></div><div>Yes, that&#39;s one of several reaso=
ns this is only a straw man, not a real proposal. One could imagine using s=
ome sort of generic byte-source and byte-sink concept instead of char*, or =
providing overloads for iostreams. Ideally, the API would cleanly support b=
oth I/O and in-place conversion. It&#39;s important, though, that the optim=
izer be able to fully inline read(), write(), and iteration operations on t=
he source/sink types, so that it can eliminate no-op loops.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>float f=
array[512];</div>
<div>read_from_file(somefile, farray, sizeof(farray));</div><div><br></div>=
<div>//Entire loop should be optimized out if host is big endian.</div><div=
>for(auto&amp; f : farray) {<br>f =3D be_to_host(f);</div><div>}</div></div=
>
</blockquote><div><br></div><div>There are two problems with this code. Fir=
st of all, you are reading uninterpreted bytes directly into float objects.=
 As discussed above, this is a bad practice; the behavior of this code is a=
t best unspecified, if not outright undefined, and I&#39;m far from convinc=
ed it&#39;s safe in practice, given the possibility of things like signalin=
g NaNs.</div>
<div><br></div><div>Second, it&#39;s not portable. It tacitly assumes that =
sizeof(float) is exactly equal to the size of floating point numbers in som=
efile&#39;s format, but this cannot be true in general, because the standar=
d does not uniquely determine sizeof(float). Worse, your comment indicates =
that=A0be_to_host does nothing but byte swapping, which means that this cod=
e is also assuming that the host uses the same floating-point format as som=
efile.</div>
<div><br></div><div>These are the exact points I wanted to emphasize with m=
y proposed API:</div><div>- The conversion API must not be symmetric: the w=
ire-format data is an uninterpreted byte sequence, and must be treated as s=
uch by the type system.</div>
<div>- The conversion API cannot be parameterized by the host type: it must=
 be parameterized by the wire format (which contains strictly more informat=
ion). It is implementation-defined whether any given host type can hold all=
 possible values of a given wire format, so the host type must be dictated =
by the API, not by the user.</div>
<div><br></div><div>Here&#39;s how I&#39;d write that code (note that I&#39=
;ve tweaked some names from my previous proposal):</div><div><br></div><div=
>char raw_array[512 * big_endian_ieee_single::wire_size];</div><div>read_fr=
om_file(somefile, farray, sizeof(farray));</div>
<div><br></div><div>typedef big_endian_ieee_single::host_type ieee_float;</=
div><div>static_assert(sizeof(ieee_float) =3D=3D big_endian_ieee_single::wi=
re_size);</div><div><br></div><div>char* ptr =3D raw_array;</div><div>// En=
tire loop should be optimized out if host supports big-endian IEEE</div>
<div>while (ptr &lt; raw_array + sizeof(raw_array)) {</div><div>=A0 reinter=
pret_cast&lt;ieee_float&gt;(ptr) =3D big_endian_ieee_single::read(ptr);</di=
v><div>=A0 ptr +=3D sizeof(ieee_float);</div><div>}</div><div><br></div><di=
v>ieee_float* float_array =3D reinterpret_cast&lt;ieee_float*&gt;(raw_array=
);</div>
<div><br></div><div>Note that the static_assert is not guaranteed to succee=
d, but it&#39;s much more likely to be true than if I was using &quot;float=
&quot; in place of the ieee_float typedef. If I wanted my code to be comple=
tely portable, I&#39;d need to allocate the raw and deserialized arrays sep=
arately, but I could probably use SFINAE tricks to do this only when sizeof=
(ieee_float) !=3D=A0big_endian_ieee_single::wire_size.<br>
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><div class=3D"h5"><di=
v><br></div>
<div>reads Policy::number_of_bytes bytes starting at c, and returns the val=
ue they represent. Similarly, if v is a value of type Policy::native_type</=
div><div><br></div><div>Policy::write(v, c);</div><div><br></div><div>
writes the encoded value of v in the Policy::number_of_bytes bytes starting=
 at c. You could even conceivably support variable-length encodings, by hav=
ing read and write update their pointer parameters, but then you have to wo=
rry about issues like buffer allocation.</div>

<div><br></div><div>You&#39;d also want to standardize at least some basic =
policy classes, covering big and little endian versions of unsigned and two=
&#39;s complement integers in various sizes, and IEEE single, double, and e=
xtended precision. I&#39;m not sure exactly how to name them; it&#39;s temp=
ting to make things like endianness and size be template parameters, but it=
&#39;s not clear how useful that is in practice, and I worry making size a =
parameter will tempt users into doing subtly wrong things like std::big_end=
ian_ieee&lt;sizeof(<u></u>double)&gt; in the name of portability.</div>

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">
<br>
This enables the following usages:<br>
uint16_t x =3D bswap&lt;uint16_t&gt;(5);<br>
uint16_t y =3D bswap(x);<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
template &lt;typename T&gt;<br>
constexpr T cpu_to_le(T t) { return byte_order::value =3D=3D byte_order::li=
ttle_endian ? t : bswap(t); }<br>
</blockquote>
<br>
I personally would prefer the wording &#39;native&#39; to &#39;cpu&#39;.<br=
>
I would move the byte_orders to template arguments (either as addition, or =
as a replacement of the above):<br>
<br>
template &lt;byte_order from, byte_order to, typename T&gt;<br>
constexpr T convertByteOrder(T t);<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
//Optional: Should we support signed integers as well?<br>
</blockquote>
<br>
IMHO yes!<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
//Optional: Should we support floating point types? Do binary formats or ha=
rdware devices need this?<br>
</blockquote>
<br>
Yes, I am sure someone will someday create a format that needs this (If it =
is not already existing).<br>
<br>
Question: Is there any architecture where integers and floating point numbe=
rs are stored in different endianesses?<br></blockquote><div><br></div><div=
>As was pointed out elsewhere in the thread, the answer is yes, and worse, =
Wikipedia refers to &quot;old ARM processors that have half little-endian, =
half big-endian floating point representation&quot;. The possibility of bou=
straphedon endianness even for integers has already come up. However, per t=
he above, we shouldn&#39;t have to care about any possible host endianness-=
 we just need to care about the formats for which it&#39;s worth standardiz=
ing the ability to read and write them.</div>

<div>=A0</div></div></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex"><div><div class=3D"h5">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
//Optional: Byte Swapping an arbitrary sized buffer? Is this at all useful?=
<br>
</blockquote>
<br>
I am not sure about this either. At least all supported integral types shou=
ld be supported.<br>
<br>
Note: For buffers std::reverse_copy could be used to realize bswap.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
//Optional: Do we need/want a macro interface?<br>
</blockquote>
<br>
I think we you have it!<br>
<br>
What I&#39;ve been missing is a function the convert the byte_order without=
 knowing the order during compilation time. e.g:<br>
<br>
template&lt;typename T&gt;<br>
constexpr T convertByteOrderRT(T t, byte_order from, byte_order to);<br>
<br>
byte_order from =3D ??; // Is set during runtime<br>
<br>
uint16_t x =3D convertByteOrderRT(v, from, little_endian);<br>
<br>
This function could also replace the &#39;convertByteOrder&#39; function me=
ntioned above.<br>
<br>
Some corner cases we probably should not care about:<br>
- Swapping of types with sizes like 6 Byte<br>
- Behavior when CHAR_BITS !=3D 8<br>
<br>
<br>
I hope these remarks are helpful for you and welcome any feedback.<br>
<br>
<br>
regards, Markus</div></div><div><div><div><div class=3D"h5"><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &quot;ISO C++ Standard - Future Proposals&quot; group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@<u></u>isoc<u></u>pp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<div class=
=3D"im"><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>iso<u><=
/u>cpp.org/group/std-<u></u>proposals/</a>.<br>
</div></div></div></blockquote></div><br></div></div></blockquote><div>I&#3=
9;ll have to consider your policy idea a bit more first. Something like tha=
t could be a better interface.</div><div><br></div><div>This brings up an i=
nteresting question. Do we actually need to expose the host byte order at a=
ll?</div>
<div>If we just provide host_to_Xe() functions, then we avoid all of these =
nasty corner cases with strange byte orders.</div><div><br></div><div>In ad=
dition, exposing the byte order also brings problems when a new architectur=
e with some byte order not in the standard list is presented.</div>
<div>User code that is written this way will break;</div><div>if(host_byte_=
order =3D=3D little_endian) {<br>=A0 //Do little endian stuff</div><div>} =
=A0else {<br>=A0 //Assume big endian</div><div>}</div><div><br></div><div>T=
his becomes impossible if there is no exposed host byte order.</div>
<div><br></div><div>So now let me ask this question. If we just provide hos=
t_to_Xe() methods for all builtin types (and optionally encourage overloads=
 for implementation specific types like simd as needed),</div><div>is there=
 ever a case where users will still need a method of determining the system=
 byte order?</div>
<div><br></div><div>Put another way, is it possible for us to account for a=
ll possible uses cases of knowing the byte order and just provide those via=
 a simple interface?</div><div>The only time I&#39;ve ever needed it is for=
 serialization.</div>
<div><br></div><div>If exposing the byte order enables an important use cas=
e that cannot be abstracted, then I&#39;d be inclined to keep it around. Ot=
herwise, do we really need it at all?</div></div></blockquote><div><br>
</div><div>The major case I&#39;m aware of is, as David mentioned, when you=
 want to translate between two formats. Notably, even in this case you don&=
#39;t actually care about the native byte order, you just want to efficient=
ly convert one well-specified format to another. We could extend the API wi=
th something like</div>
<div><br></div><div>template &lt;typename SourcePolicy, typename SinkPolicy=
&gt;</div><div>void convert_byte_format(const char* source, char* sink);</d=
iv><div><br></div><div>which the implementation can specialize appropriatel=
y (an interesting but solvable challenge would be to extend this to support=
 user-defined policies). However, that may be over-engineering; this use ca=
se seems too marginal to warrant much standardization effort, and a separat=
e API may not be needed: you can just code this in terms of the to-host/fro=
m-host API</div>
<div><br></div><div>char* source, sink;</div><div>// Initialize source and =
sink</div><div>while (have_more_input) {</div><div>=A0 SourcePolicy::host_t=
ype tmp =3D SourcePolicy::read(source);</div><div>=A0 SourcePolicy::write(t=
mp, sink);</div>
<div>=A0 // increment source and sink</div><div>}</div><div><br></div><div>=
and rely on the optimizer to generate efficient code. I&#39;d expect a dece=
nt optimizer to be able to turn this into a minimal number of byte-swaps an=
d copies, and to completely eliminate the loop when the source and sink hav=
e the same endianness.</div>
<div><br></div><div>In case it wasn&#39;t clear, I don&#39;t support exposi=
ng the host byte order in a standard API: It would be annoyingly hard to st=
andardize such an API in the face of mixed endianness, dynamic endianness, =
and other complicating factors, and the result would likely be an &quot;att=
ractive nuisance&quot; rather than a genuinely useful utility. The people w=
ho really need it are probably already living in the land of implementation=
-defined behavior, so they can just use vendor extensions.=A0</div>
</div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c253c02c323204e8520c66--

.

--047d7b5d6018ae296404e8559e0b
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 1, 2013 at 11:59 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 2 October 2013 06:56, <fmatthew5876@gmail.com> wrote:
>
>> This proposal should be generalized to a more generic byte swapping
>> solution. Something like:
>>
>
> We know. :)
>
>
>> This is so easy and trivial to implement. Most compilers even have
>> builtins for all of the byte swapping routines. I don't know why its not
>> standardized.
>>
>>
>>
> It's not standardized because networking didn't need the generic solution
> and I don't recall
> seeing a proposal for the generic one.
>

With help from a lot of others, I've had a generic Endian library accepted
by Boost, subject to dealing with a number of concerns. Those concerns have
now been dealt with, so I'm hoping the library will go into Boost trunk in
the next few weeks and ship with Boost release 1.56.  The library handles
both endian conversions and endian types, and would presumably be suitable
for a standard library TS proposal.

See github.com/beman/endian

--Beman

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b5d6018ae296404e8559e0b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Oct 1, 2013 at 11:59 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><div=
 class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div class=3D"im"=
>On 2 October 2013 06:56,  <span dir=3D"ltr">&lt;<a href=3D"mailto:fmatthew=
5876@gmail.com" target=3D"_blank">fmatthew5876@gmail.com</a>&gt;</span> wro=
te:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Thi=
s proposal should be generalized to a more generic byte swapping solution. =
Something like:</div>

</div></blockquote><div><br></div></div><div>We know. :)<br>=A0</div><div c=
lass=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div>
</div><div>This is so easy and trivial to implement. Most compilers even ha=
ve builtins for all of the byte swapping routines. I don&#39;t know why its=
 not standardized.</div>
</div><span><font color=3D"#888888">

<p></p>

<br></font></span></blockquote><div><br></div></div><div>It&#39;s not stand=
ardized because networking didn&#39;t need the generic solution and I don&#=
39;t recall<br>seeing a proposal for the generic one.<br></div></div></div>
</div></blockquote></div><br>With help from  a lot of others, I&#39;ve had =
a generic Endian library=20
accepted by Boost, subject to dealing with a number of concerns. Those=20
concerns have now been dealt with, so I&#39;m hoping the library will=20
go into Boost trunk in the next few weeks and ship with Boost release=20
1.56.=A0 The library handles both endian conversions and endian types, and
 would presumably be suitable for a standard library TS proposal.<br><br>Se=
e <a href=3D"http://github.com/beman/endian">github.com/beman/endian</a><br=
><br></div><div class=3D"gmail_extra">--Beman<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b5d6018ae296404e8559e0b--

.

------=_Part_2957_10925939.1382315256759
Content-Type: text/plain; charset=ISO-8859-1

I'm going to put this on hold for now and focus on my other bitwise
operators proposal (which may end up containing generic byte reversal
routines). We can revisit the idea later.
Perhaps the best way would be to use Beman's library and build from there.

On Wednesday, October 9, 2013 5:32:18 PM UTC-4, Beman Dawes wrote:
>
> On Tue, Oct 1, 2013 at 11:59 PM, Ville Voutilainen <ville.vo...@gmail.com<javascript:>
> > wrote:
>
>>
>>
>>
>> On 2 October 2013 06:56, <fmatth...@gmail.com <javascript:>> wrote:
>>
>>> This proposal should be generalized to a more generic byte swapping
>>> solution. Something like:
>>>
>>
>> We know. :)
>>
>>
>>> This is so easy and trivial to implement. Most compilers even have
>>> builtins for all of the byte swapping routines. I don't know why its not
>>> standardized.
>>>
>>>
>>>
>> It's not standardized because networking didn't need the generic solution
>> and I don't recall
>> seeing a proposal for the generic one.
>>
>
> With help from a lot of others, I've had a generic Endian library accepted
> by Boost, subject to dealing with a number of concerns. Those concerns have
> now been dealt with, so I'm hoping the library will go into Boost trunk in
> the next few weeks and ship with Boost release 1.56.  The library handles
> both endian conversions and endian types, and would presumably be suitable
> for a standard library TS proposal.
>
> See github.com/beman/endian
>
> --Beman
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_2957_10925939.1382315256759
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I'm going to put this on hold for now and focus on my othe=
r bitwise operators proposal (which may end up containing generic byte reve=
rsal routines). We can revisit the idea later.&nbsp;<div>Perhaps the best w=
ay would be to use Beman's library and build from there.<br><br>On Wednesda=
y, October 9, 2013 5:32:18 PM UTC-4, Beman Dawes wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">O=
n Tue, Oct 1, 2013 at 11:59 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"9YwD9TAZbvI=
J">ville.vo...@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><div=
><br><br><div class=3D"gmail_quote"><div>On 2 October 2013 06:56,  <span di=
r=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"9YwD9TAZbvIJ">fmatth...@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Thi=
s proposal should be generalized to a more generic byte swapping solution. =
Something like:</div>

</div></blockquote><div><br></div></div><div>We know. :)<br>&nbsp;</div><di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>
</div><div>This is so easy and trivial to implement. Most compilers even ha=
ve builtins for all of the byte swapping routines. I don't know why its not=
 standardized.</div>
</div><span><font color=3D"#888888">

<p></p>

<br></font></span></blockquote><div><br></div></div><div>It's not standardi=
zed because networking didn't need the generic solution and I don't recall<=
br>seeing a proposal for the generic one.<br></div></div></div>
</div></blockquote></div><br>With help from  a lot of others, I've had a ge=
neric Endian library=20
accepted by Boost, subject to dealing with a number of concerns. Those=20
concerns have now been dealt with, so I'm hoping the library will=20
go into Boost trunk in the next few weeks and ship with Boost release=20
1.56.&nbsp; The library handles both endian conversions and endian types, a=
nd
 would presumably be suitable for a standard library TS proposal.<br><br>Se=
e <a href=3D"http://github.com/beman/endian" target=3D"_blank">github.com/b=
eman/endian</a><br><br></div><div>--Beman<br></div></div>
</blockquote></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2957_10925939.1382315256759--

.