From: me22 (me22.ca_at_[hidden])
Date: 2006-05-31 15:38:58
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?
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
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).
I'm still not convinced that these types are a better solution than a
simple input/output wrapper allowing something along the lines of
infile >> big_endian<3>(x);
x *= 13;
outfile << little_endian<3>(x);
~ Scott McMurray
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk