Re: [boost] Portable binary integers [was generic polyvalent I/O]

From: Darin Adler (darin_at_[hidden])
Date: 2000-11-16 13:19:57

on 11/16/00 8:29 AM, Beman Dawes at beman_at_[hidden] wrote:

> IIRC, Mark Borgerding, Darin Adler, and I all discussed portable binary
> integer classes we use in our own work.  They range from minimalist to much
> more complete, big endian only to both big and little endian.  Some people
> think that portable integer classes should act like full-fledged arithmetic
> objects, others (or at least me) see them as representation holders useful
> for I/O but to be converted to built-in types for any arithmetic
> operations. Beyond data portability, maximum code portability requires such
> classes be POD's and that argues for minimalist rather than maximalist
> designs, IMO. Still other people viewed the need in terms of operations on
> streams, without a need for actual objects.
> 
> Although there was no consensus on those kinds of design questions, there
> did seem to be consensus by those who had used them that portable binary
> integer classes are very useful or even essential for lots of practical
> applications.

Just a quick reminder about my "angle of attack" on this problem.

I found that endian-specific integer types that supported close to the full
set of operations on integers helped me in projects where I was porting
existing code. I found that I could substitute endian-specific integer types
for native integer types, and usually didn't have to make any other code
changes.

This is an argument for the "full-fledged arithmetic objects" approach,
although in practice I started with a minimal class and added to it as
needed in various projects. The idea was that it's safer to add to this
class than to make changes to the code I'm porting.

This worked *extremely* well on at least 3 major porting projects where I
had to make code that was unintentionally little-endian specific instead be
endian-neutral -- I think this approach saved me days of work each time.
Note that since some of the data structures were already defined implicitly
to be little-endian by the original (Windows) programmers data files, a
big-endian-only solution would not have helped me.

    -- Darin