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

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-11-16 15:27:29

> My feeling has always been that a compact, machine-independent,
> variable-length number representation (e.g. high bit set indicates the end
> of the number) was the way to go if you care about portability at all. The
> length of an int/long/char/short/wchar_t/float/double... on any given
> machine is too variable to make this work otherwise. It's also nice because
> you can detect overflows.

That works, although it wastes some space and time.  It seems that if
you provide 1,2,4, and 8 byte signed and unsigned integers and 4 and
8 byte IEEE floats you have pretty well covered the waterfront.

> -Dave
> ----- Original Message -----
> From: "Gary Powell" <Gary.Powell_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Thursday, November 16, 2000 1:32 PM
> Subject: RE: [boost] Portable binary integers [was generic polyvalent I/O]
> 
> 
> > >my "angle of attack" on this problem.
> >
> > I was thinking along the line of having a full set of operators, which if
> > you selected "arithmetic<native>" "input<BigEndian>"
> "output<LittleEndian>"
> > traits would do conversion on operator>>, and operator<<, or you could
> > select "arithmetic<big_endian>" "input<native> output<native>", or some
> > combination of these. and it would do it that way instead.  It would rely
> on
> > a compiler to optimize all the inline operators away. The library code
> would
> > be fairly complex, but the usage would be simple, just replace the types
> and
> > specify the usage.  Addition of new formats would be done with the
> addition
> > of new traits templates. With a good design it would be a linear increase
> in
> > code, not an exponential one.
> >
> >   -gary-
> >
> > gary.powell_at_[hidden]
> >
> >
> >
> >
> 
> 
> 
> 
>