Re: [boost] Re: endian handling classes

From: Darin Adler (darin_at_[hidden])
Date: 2000-04-11 09:42:14

on 4/11/00 7:05 AM, Beman Dawes at beman_at_[hidden] wrote:

> * Should the portable integers directly support usual arithmetic
> operations?  Or is it better to indirectly (via conversions from/to
> integral types) support arithmetic operations?  It seems to me there
> are many advantages of the indirect approach; much simpler
> implementation (which seems particularly desirable for portable
> integers; you don't want people assuming these things are useful
> beyond their specialized designed uses), faster operation, etc.
> OTOH, I see Darin did supply full arithmetic operations.

I find that supporting the usual arithmetic operations is quite useful for
one of the most common uses for these types. That use is substituting onf of
these types in existing code to make it work on a new platform. In this
case, I want to minimize the amount of other code that I need to edit. In
most cases, I add an include and change the type of a member in a struct
definition.

> * Should both big-endian and little-endian external representations
> be supported?  I always assumed the defacto-standard was big-endian,
> both for historical reasons and because file dumps are easier to
> read, but other implementations supply both.

When I port from Windows to Macintosh, it's useful to have a little-endian
representation, since often the structs define an existing data structure.
By the time I'm porting, it's too late to choose big-endian for the format.

> * Is there a need for memory aligned flavors?  Darin, could you
> educate me as to what uses you had in mind for aligned versions?

The aligned versions work better for this case of substituting a new type in
existing code. Often the structure alignment rules match perfectly and thus
it's useful to have the aligned version.

    -- Darin