Re: [boost] Endian library - request for comments

From: me22 (me22.ca_at_[hidden])
Date: 2006-05-31 15:38:58

On 5/31/06, Beman Dawes <bdawes_at_[hidden]> wrote:
> That's because in the Geographic applications I work on, every
> additional byte gets multiplied by 50 or 100 million (because that is
> how many records it takes to represent the US and Canada, without even
> mentioning the rest of the world.) So a designer thinks in terms of
> bytes, not eight bit multiples.
>
> My original classes didn't support arithmetic operations. But Darin
> Adler and several others argued that it was much easier if all were
> supported. I went back and reviewed old code and found they were right.
> Providing a full set of operations reduced program clutter and made for
> code both easier to write and to read. I became a believer.
>

It sounds like the main advantage you're getting here is the reduced
space requirement.  Can you elaborate why the endianness is important
for you here?

I think that it might be most useful were the code adapted to become
an addition to Boost.Integer, so that one could use, for example,
boost::int_t<24>::exact and get a type requiring only 3 bytes of
storage, assuming CHAR_BIT==8. ( Obviously with no guarantee of a
specific endianness or that it would be a fundamental type and perhaps
STATIC_ASSERT'ing for bit lengths not a multiple of CHAR_BIT.  )  It
would be another option for a space/speed trade-off as with ::fast vs
::least.

On 5/31/06, Cliff Green <cliffg_at_[hidden]> wrote:
> I've never had a need for code that
> performs operations on endian types, other than as
> "placeholders" for performing I/O with them (whether over
> a network, or disk I/O).

Agreed.

I'm still not convinced that these types are a better solution than a
simple input/output wrapper allowing something along the lines of
long x;
infile >> big_endian<3>(x);
x *= 13;
outfile << little_endian<3>(x);

~ Scott McMurray