Rene Rivera wrote:
Beman Dawes wrote:
"me22" <me22.ca@gmail.com> wrote in message news:fa28b9250605310817l2d71b783j9e92bd247619d313@mail.gmail.com...
On 5/31/06, Beman Dawes <bdawes@acm.org> 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