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 09:22:33

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.

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

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.

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

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