On 5/31/06, Beman Dawes <bdawes@acm.org> 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@codewrangler.net> 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