Re: [boost] [boost::endian] Request for comments/interest

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-05-27 10:20:09

----- Original Message ----- 
From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, May 27, 2010 4:04 PM
Subject: Re: [boost] [boost::endian] Request for comments/interest

> 
> vicente.botet wrote:
>> Rob Stewart wrote:
>> > Terry Golubiewski wrote:
>> >
>> >> With Beman's approach there is no extra overhead if the
>> >> native type == endian type.
>> >
>> > In many cases, write format is big endian and the host is
>> > little, so that assertion is small comfort.
>>
>> What the OP intend to say is that when we convert from  the
>> same endian there is no extra overload.
> 
> I understood that.  My point was that the swapping scenario is very common, so the overhead will also be common.
> 
>> But even this is not true, as Beman's implementation will do
>> a copy as there is no in-place operations, as you bellow.
> 
> I didn't realize I was bellowing about anything and I wasn't the one to introduce the idea of in-place swapping.  Nevertheless, copying built-in types is trivial and should lend itself readily to optimization in many cases, so the difference should be small, if not zero.
> 
>> >> Beman's approach does provide several operators for
>> >> endian-swappable types, but I just don't use those
>> >> operations, preferring to extract to native,
>> >> perform operations, and then store the result.
>> >
>> > That the operations are provided for types that look and
>> > act like built-ins suggests that the operations are just as
>> > efficient.  In the big/wire, little/host scenario, simple
>> > looking expressions can be rife with inefficiency.
>> > Expression templates could be employed to reduce those
>> > inefficiencies, of course, but as you note, when one is going
>> > to do much with the values, it is better to swap once and
>> > then work with the natively ordered value.
>>
>> We can remove all the operations of the Beman's typed
>> approach, so no risk to over use of. Without no operations,
>> the Beman's classes must be used just to convert from some
>> endiannes to the native and vice-versa, and then operate on
>> the native types.
> 
> At that point, however, the functional approach seems more straightforward.
> 
>> > Tomas' and my APIs are geared toward the latter approach.
>> > Beman's design tends to encourage the former.  Nevertheless,
>> > I understand that less demanding applications would benefit
>> > from the safety of Beman's approach, so both are worthwhile.
>>
>> IMO the single case when your and Tomas approach can be more
>> efficient is when you use in_place conversions, as you are
>> able to do nothing when the endianness is the same. The other
>> case, i.e., conversion from one variable to another, is
>> better handled by Beman's approach, as it is type safe and is
>> should not be less efficient than yours.
> 
> If you remove the operators from Beman's types, then its a question of syntax and, possibly, safety.  However, I don't see any type safety problems in my original or hybrid APIs.

The problem is that we don't know the endiannes of the types int32_t or long. This depends on the operation you have performed on your code. E.g.

   int32_t wire(/* from wire */);
   long l1;
   long l2;
   to_big_endian(l1, l2);
   to_big_endian(l2, wire);
 
With the typed endians this is not possible.
   big32_t wire(/* from wire */);
   long l1;
   long l2;
   l2=l1; // no endian change as both are native
   wire=l2; // conversion to big from native.

Best,
Vicente