Re: [boost] Endian library - request for comments

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-06-02 10:51:22

"me22" <me22.ca_at_[hidden]> wrote in message 
news:fa28b9250605311238t323effai49e2d275e8376eff_at_mail.gmail.com...
> 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?

If endianness isn't important, these are the wrong classes to use. Both the 
space saving and portability (ie. endianness) is important in my apps, but 
the portability is by far the strongest motivation for these classes.

I've reworked the docs and example to hopefully make that clearer. In 
reworking the example, I used part of a file format that is a de facto 
standard in the GIS industry. It contains both big and little endian 
integers. (Don't ask - I have no idea why it was designed that way - I 
wasn't the designer.)

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

I've exposed the integer_cover_operators template and moved it to a separate 
header to make it generally available. I like your suggestion to make it 
part of Boost.Integer - I hadn't thought of that.

Asside: Would it also work for floating-point types? Once we have Concepts, 
the compiler will tells us in an instant!

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

Let's say you have to increment a variable in a record. It is very 
convenient to be able to write:

   ++record.foo.

Rather than:

    int temp( record.foo);
    ++temp;
    record.foo = temp;

Now I know that automatic conversions in some "placeholder" style endian 
classes make them pretty convenient, but there is no additional cost to 
providing the arithmetic operations. If you don't need/want/like them, don't 
use them.

> 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);

That's fine for small examples, but gets old for large production programs. 
The experience reports from Darin and others who have been using endian 
classes with full arithmetic ops have also been convincing.

Thanks,

--Beman