From: David Abrahams (abrahams_at_[hidden])
Date: 2000-11-16 15:23:57
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.
----- Original Message -----
From: "Gary Powell" <Gary.Powell_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>"
> 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
> a compiler to optimize all the inline operators away. The library code
> be fairly complex, but the usage would be simple, just replace the types
> specify the usage. Addition of new formats would be done with the
> of new traits templates. With a good design it would be a linear increase
> code, not an exponential one.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk