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 09:51:16

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

> 
> Terry Golubiewski wrote:
> 
> [please don't top post]
> 
>> 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. 
But even this is not true, as Beman's implementation will do a copy as there is no in-place operations, as you bellow.

>> If you use Beman's endian only for over-the-wire messages and
>> then extract the endian-aware types in/out to native types,
>> then I think Beman's efficiency is very good.
> 
> That involves copying all of the data.  In many cases, the extra data copying is too expensive.
> 
>> 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.

> 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 endianess 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.

>> Also, network-byte-order isn't the only "correct"
>> over-the-wire byte order.  Some of us still believe that
>> little-endian is better. (Don't take the bait). ;o)
> 
> I absolutely agree that local conventions can make that work well.  The fact is, however, that the Internet is based upon big-endian ordering and that is a strong influence on many applications.
> 
>> Since the endian issue is larger than network-byte-ordering,
>> I would suggest removing any such references.
> 
> Those were only in the (existing) API that I posted illustrating an alternative to Tomas' API, as I'm sure you're now aware.

I agree that the interface must be network neutral, only endiannes is the concern.

Best,
Vicente