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

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-05-27 10:04:53

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.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.