Re: [boost] Re: endian handling classes

From: Beman Dawes (beman_at_[hidden])
Date: 2000-04-11 09:05:10

At 02:11 PM 3/11/00 -0800, Darin Adler wrote:

>I put a cut at endian.hpp up in the vault
><http://www.egroups.com/docvault/boost/endian/endian.hpp>. I didn't
enclose
>it because I don't trust my email program to put it in a form you
all will
>like.
>
>I tested it out with CodeWarrior. It needs more comments and a test
program,
>but this is all I have time for at the moment. Many of the binary
arithmetic
>operators could have slightly more efficient implementations. This
might
>need a little dumbing down to work with Visual C++, just as
operators.hpp
>did.

Sorry to take so long to reply to this.  Been traveling and tearing
up office for renovations.

It seems to me that we need to step back and define the requirements
for portable integers before we get into code. Portable integers is
one of those apparently simple ideas which keep getting reinvented
all the time, but have various non-obvious requirements, so the
inventions are often don't really do the job.

I added a file to the vault (which eGroups now seems to be calling
the "Files") with the requirements I am fairly certain of.  I would
like to get others reactions.  See
http://www.egroups.com/files/boost/endian/port_int_req.html

I didn't include anything regarding various issues I see as open
questions:

* 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.

* 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.

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

* If templatized, do the benefits outweigh the added complexity?

* If templatized, are there protections against invalid parameter
values (such as coding parameter values that would require something
other than 8-bit bytes in external values.)

--Beman