----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> 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