------=_Part_291_29855935.1355721039015
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I think this two features could help a lot of programmers out:

1. Compile time endianness checking. As far as I know, there's no way to do
that right now, even with constexpr. (The usual method is casting a
uint16_t* to a uint8_t* and checking it's value.) With the C++ approach to
do many things at compile time, this information could be extremely helpful
to some low-level algorithms. (e.g. SHA-2) I also think the compiler has
this information anyway, since he has to put constant values in memory.
(int i = 12345, layout for 12345 must be known at compile time. ?) This
could be done by just setting some enum std::platform_endianness.

2. Overflow-checks. While many (most?) CPUs have some kind of
carry/overflow bit, getting the compiler to actually use this information
doesn't seem straight forward or even possible for all cases to me. The
usual C++ approach is to use some arithmetic "tricks" to figure out if an
operation would overflow or not. In most cases this seems to be much slower
than just using the dedicated CPU flags. With library functions like

  bool std::safe_multiply(uint32_t a, uint32_t b, uint32_t& c)
  bool std::safe_multiply(int32_t a, int32_t b, int32_t& c) // State of c
is implementation-/undefined if function returns false
// Add functions for addition etc., for all integer types.

the implementation could actually use the scope of the platform to provide
optimal performance in a standard conforming way. I think this feature
could be very useful for things like safe_int or unsigned_integer<uint64_t,
8> (arbitrary precision).

Okay, now have fun destroying me. :)

--




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

Hi, <br><br>I think this two features could help a lot of programmers out:<=
br><br>1. Compile time endianness checking. As far as I know, there's no wa=
y to do that right now, even with constexpr. (The usual method is casting a=
 uint16_t* to a uint8_t* and checking it's value.) With the C++ approach to=
 do many things at compile time, this information could be extremely helpfu=
l to some low-level algorithms. (e.g. SHA-2) I also think the compiler has =
this information anyway, since he has to put constant values in memory. (in=
t i =3D 12345, layout for 12345 must be known at compile time. ?) This coul=
d be done by just setting some enum std::platform_endianness.<br><br>2. Ove=
rflow-checks. While many (most?) CPUs have some kind of carry/overflow bit,=
 getting the compiler to actually use this information doesn't seem straigh=
t forward or even possible for all cases to me. The usual C++ approach is t=
o use some arithmetic "tricks" to figure out if an operation would overflow=
 or not. In most cases this seems to be much slower than just using the ded=
icated CPU flags. With library functions like<br><br>&nbsp; bool std::safe_=
multiply(uint32_t a, uint32_t b, uint32_t&amp; c) <br>&nbsp; bool std::safe=
_multiply(int32_t a, int32_t b, int32_t&amp; c) // State of c is implementa=
tion-/undefined if function returns false<br>// Add functions for addition =
etc., for all integer types.<br><br>the implementation could actually use t=
he scope of the platform to provide optimal performance in a standard confo=
rming way. I think this feature could be very useful for things like safe_i=
nt or unsigned_integer&lt;uint64_t, 8&gt; (arbitrary precision).<br><br>Oka=
y, now have fun destroying me. :)<br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_291_29855935.1355721039015--

.

On Mon, Dec 17, 2012 at 12:10 AM,  <cooky451@gmail.com> wrote:
> Hi,
>
> I think this two features could help a lot of programmers out:
>
> 1. Compile time endianness checking. As far as I know, there's no way to do
> that right now, even with constexpr. (The usual method is casting a
> uint16_t* to a uint8_t* and checking it's value.) With the C++ approach to
> do many things at compile time, this information could be extremely helpful
> to some low-level algorithms. (e.g. SHA-2) I also think the compiler has
> this information anyway, since he has to put constant values in memory. (int
> i = 12345, layout for 12345 must be known at compile time. ?) This could be
> done by just setting some enum std::platform_endianness.

My guess is that a well thought out endianness proposal would sail
through the committee.

Think about how the standard already specifies such things. It's an
implementation property. So the target would like be <limits>, and
C++14.

Perhaps something like:
   constexpr endian endianness() noexcept;

Where endian is an enum class with big, little, and possibly some
others defined.

Figure out how to handle odd-ball endianness. Maybe allow endian to
have an additional implementation defined member if the endianness
isn't big or little.

Write a proposal. The committee is an all volunteer organization. If
you don't volunteer to write the proposal, it is doubtful anyone else
will step forward.

In the proposal, don't speculate on how such a function might be
implemented, other than saying it might require compiler support. Do
mention the many times similar features have been implemented, usually
by macros such as in the Boost endian.hpp header.

Send me the proposal. I'll get a number assigned and champion it
before the committee. Or show up at the next meeting (Bristol, UK, in
April) and champion it yourself:-)

--Beman

--




.

On 2012-12-17 06:10, cooky451@gmail.com wrote:

> 1. Compile time endianness checking. As far as I know, there's no way to
> do that right now, even with constexpr. (The usual method is casting a
> uint16_t* to a uint8_t* and checking it's value.) With the C++ approach

Sometimes endianness can only be detected correctly at run-time. See

   http://sourceforge.net/p/predef/wiki/Endianness/

--




.

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

On Dec 17, 2012 5:00 PM, "Beman Dawes" <bdawes@acm.org> wrote:
>
> On Mon, Dec 17, 2012 at 12:10 AM,  <cooky451@gmail.com> wrote:
> > Hi,
> >
> > I think this two features could help a lot of programmers out:
> >
> > 1. Compile time endianness checking. As far as I know, there's no way
to do
> > that right now, even with constexpr. (The usual method is casting a
> > uint16_t* to a uint8_t* and checking it's value.) With the C++ approach
to
> > do many things at compile time, this information could be extremely
helpful
> > to some low-level algorithms. (e.g. SHA-2) I also think the compiler has
> > this information anyway, since he has to put constant values in memory.
(int
> > i = 12345, layout for 12345 must be known at compile time. ?) This
could be
> > done by just setting some enum std::platform_endianness.
>
> My guess is that a well thought out endianness proposal would sail
> through the committee.
>
> Think about how the standard already specifies such things. It's an
> implementation property. So the target would like be <limits>, and
> C++14.
>
> Perhaps something like:
>    constexpr endian endianness() noexcept;
>
> Where endian is an enum class with big, little, and possibly some
> others defined.
>
> Figure out how to handle odd-ball endianness. Maybe allow endian to
> have an additional implementation defined member if the endianness
> isn't big or little.
>
> Write a proposal. The committee is an all volunteer organization. If
> you don't volunteer to write the proposal, it is doubtful anyone else
> will step forward.
>
> In the proposal, don't speculate on how such a function might be
> implemented, other than saying it might require compiler support. Do
> mention the many times similar features have been implemented, usually
> by macros such as in the Boost endian.hpp header.
>
> Send me the proposal. I'll get a number assigned and champion it
> before the committee. Or show up at the next meeting (Bristol, UK, in
> April) and champion it yourself:-)
>
> --Beman
>
> --
>
>
>
Do keep in mind that endianness facilities are already being worked on by
SG4.

--




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

<p><br>
On Dec 17, 2012 5:00 PM, &quot;Beman Dawes&quot; &lt;<a href=3D"mailto:bdaw=
es@acm.org">bdawes@acm.org</a>&gt; wrote:<br>
&gt;<br>
&gt; On Mon, Dec 17, 2012 at 12:10 AM, =A0&lt;<a href=3D"mailto:cooky451@gm=
ail.com">cooky451@gmail.com</a>&gt; wrote:<br>
&gt; &gt; Hi,<br>
&gt; &gt;<br>
&gt; &gt; I think this two features could help a lot of programmers out:<br=
>
&gt; &gt;<br>
&gt; &gt; 1. Compile time endianness checking. As far as I know, there&#39;=
s no way to do<br>
&gt; &gt; that right now, even with constexpr. (The usual method is casting=
 a<br>
&gt; &gt; uint16_t* to a uint8_t* and checking it&#39;s value.) With the C+=
+ approach to<br>
&gt; &gt; do many things at compile time, this information could be extreme=
ly helpful<br>
&gt; &gt; to some low-level algorithms. (e.g. SHA-2) I also think the compi=
ler has<br>
&gt; &gt; this information anyway, since he has to put constant values in m=
emory. (int<br>
&gt; &gt; i =3D 12345, layout for 12345 must be known at compile time. ?) T=
his could be<br>
&gt; &gt; done by just setting some enum std::platform_endianness.<br>
&gt;<br>
&gt; My guess is that a well thought out endianness proposal would sail<br>
&gt; through the committee.<br>
&gt;<br>
&gt; Think about how the standard already specifies such things. It&#39;s a=
n<br>
&gt; implementation property. So the target would like be &lt;limits&gt;, a=
nd<br>
&gt; C++14.<br>
&gt;<br>
&gt; Perhaps something like:<br>
&gt; =A0 =A0constexpr endian endianness() noexcept;<br>
&gt;<br>
&gt; Where endian is an enum class with big, little, and possibly some<br>
&gt; others defined.<br>
&gt;<br>
&gt; Figure out how to handle odd-ball endianness. Maybe allow endian to<br=
>
&gt; have an additional implementation defined member if the endianness<br>
&gt; isn&#39;t big or little.<br>
&gt;<br>
&gt; Write a proposal. The committee is an all volunteer organization. If<b=
r>
&gt; you don&#39;t volunteer to write the proposal, it is doubtful anyone e=
lse<br>
&gt; will step forward.<br>
&gt;<br>
&gt; In the proposal, don&#39;t speculate on how such a function might be<b=
r>
&gt; implemented, other than saying it might require compiler support. Do<b=
r>
&gt; mention the many times similar features have been implemented, usually=
<br>
&gt; by macros such as in the Boost endian.hpp header.<br>
&gt;<br>
&gt; Send me the proposal. I&#39;ll get a number assigned and champion it<b=
r>
&gt; before the committee. Or show up at the next meeting (Bristol, UK, in<=
br>
&gt; April) and champion it yourself:-)<br>
&gt;<br>
&gt; --Beman<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt;<br>
&gt;<br>
Do keep in mind that endianness facilities are already being worked on by S=
G4.</p>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--e89a8ff1c6c838784704d10dfb1c--

.

On Mon, Dec 17, 2012 at 10:24 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
....
>>
> Do keep in mind that endianness facilities are already being worked on by
> SG4.

Do you have a Doc number for that?

Is their work limited to a networking context? The arithmetic
endianness discussed in this thread would presumably fall under SG6,
Numerics, once LEWG passes any proposal to them.

--Beman

--




.

On 17 December 2012 17:53, Beman Dawes <bdawes@acm.org> wrote:
>> Do keep in mind that endianness facilities are already being worked on by
>> SG4.
> Do you have a Doc number for that?

Not yet, I got the impression that Kyle was about to create such a document
before the end of the year.

> Is their work limited to a networking context? The arithmetic
> endianness discussed in this thread would presumably fall under SG6,
> Numerics, once LEWG passes any proposal to them.

In this case I wouldn't expect to see a minimal only-what-networking-needs
proposal, since networking just needs the equivalent of hton* and ntoh*, but
I suppose querying system endianness (preferably without having to hton a 0x00ff
and checking whether it changed) and performing endianness swaps would
be good tools to have in general. I don't know whether there's
anything more special
in the arithmetic sense.

It seems this would be a good area for close cooperation between LEWG and SG4,
and also SG6 if need be.

--




.