Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-11-16 15:42:01


It /saves/ lots of space if most of your numbers are near 0, which is
common.

-Dave

----- Original Message -----
From: "Greg Colvin" <gcolvin_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, November 16, 2000 3:27 PM
Subject: Re: [boost] Portable binary integers [was generic polyvalent I/O]

> > 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]
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk