Boost logo

Boost :

From: Mark Borgerding (mborgerding_at_[hidden])
Date: 2000-03-10 22:00:30

darin adler <dari-_at_[hidden]> wrote:
original article:
> I have classes like this too.
> Comments:
> 1) It's possible to write an implementation that does not require
> LITTLE_ENDIAN_MACHINE #define to work properly by reading the data a
byte at
> a time. It might not be as efficient but it's more portable.

I would prefer keeping it the way it is because it keeps the
implementation as efficient as possible for a given platform. If the
machine is little-endian, no extra work goes into using
little_endian<int>, and vice versa.

Wouldn't this be a good place for compile-time asserts?

> 2) I've also found it useful to have "non-aligned" numeric
> that do the same thing but are made out of arrays of characters. This
> useful when I'm making structures to match data structures with
> characteristics different from the platform/compiler I'm using. I'll
> further if this is not sufficiently clear.

Sounds interesting. Can you do this without the use of compiler tags
like "#pragma pack" or "__attribute__ aligned" ?

> 3) I see no reason to omit the other assignment operators like
+=, -=,
> ++, and --. In a library for myself I might not bother, but for
> I'm sharing I'd like that.

My original thinking was that to do so would mislead the user into
thinking that ++n would be faster than n = n + 1. Which is not really
true for the case where byte order does not match the native type's.

Disallowing these operations was my way of telling the user, "If youu
are really worried about the speed of arithmetic operations on this
data, convert it to a native type". I think the template versions
perform reasonably fast, but I don't want people thinking that they
will be every bit as fast as the native types.

The other reason I didn't add the operators is I think its cooler than
cheez-whiz that a class can do so much with just a constructor and a
single operator. :)

- Mark

Boost list run by bdawes at, gregod at, cpdaniel at, john at