From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-06-02 10:51:22
"me22" <me22.ca_at_[hidden]> wrote in message
> 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
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).
Let's say you have to increment a variable in a record. It is very
convenient to be able to write:
int temp( record.foo);
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk