Re: [boost] Endian library - request for comments

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-05-31 14:44:32

Rene Rivera wrote:
> Beman Dawes wrote:
>> "me22" <me22.ca_at_[hidden]> wrote in message 
>> news:fa28b9250605310817l2d71b783j9e92bd247619d313_at_mail.gmail.com...
>>> On 5/31/06, Beman Dawes <bdawes_at_[hidden]> wrote:
> 
>> That said, I guess there could be an argument to expose the templates for 
>> those who prefer them.
> 
> Or, if those templates are sufficiently generic, exposing them for the 
> case for different kinds of endianness. In those rare cases when you are 
> emulating some strange hardware :-)
> 
>>> I think the names for the types might be a little bit too cute.  "bin"
>>> makes me think binary, not signed big-endian.  That being said, I'm
>>> not sure I have any good name that isn't far too verbose.
>>> unsigned_littleendian_aligned<4> is admittedly starting to push
>>> convenience, though bigendian<5> isn't too bad.
>> I'm often amazed at the clever names Boosters suggest, so I think it is 
>> worthwhile to speculate a bit about better names. But the everyday use 
>> typedefs really do need to be short and memorable. I've been using the 
>> "bin2", "bun3", etc. since 1984 or so, with several hundred programmers now 
>> using them all the time, and never had a request to change the names.
> 
> Since name suggestions are up... My main problem with the bin*, bun* 
> names is that you have to train yourself to know what they mean. It 
> might be easy after a while but they don't say anything to me initially 
> (even with the explanatory chart). My suggestion would be to stick close 
> to the existing cstdint types:
> 
> int_be8_t
> int_le8_t
> uint_be8_t
> uint_le8_t
> 
> etc.

or:

     int_b8_t
     int_l8_t
     uint_b8_t
     uint_l8_t

or:

     int_b1_t
     int_l1_t
     uint_b1_t
     uint_l1_t

> Of course that means using bit sizes instead of byte sizes. But I find 
> the bit sizes more natural anyway :-)

I tried it both ways over the years. The problem with using bit sizes is 
that a programmer is often counts these things, and always in terms of 
bytes. Bytes is just more convenient than bits.

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.

Also, working in terms of bytes seems to signal to readers that 
something special is going on - int_b32_t is more likely to be 
mistakenly viewed as just another typedef for an int32_t than bin4 or 
bin4_t.

> 
>> A more typical use might be something like:
>>
>>   struct header_record
>>   {
>>      bun3 version;
>>      bun1 rev;
>>      bun5 nrecs;
>>      ..... blah blah blah
>>   };
> 
> One question I have is... How common is it to need all the various 
> arithmetic operators in these types? All my use cases of endianness 
> handling are solved by a single specialized byteswap() function. And 
> hence see the utility of having the type do it for me, but not the 
> utility of the operators.

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.

Thanks for the comments,

--Beman