[boost] Re: Integer library: bin_ubin

From: Beman Dawes (beman_at_[hidden])
Date: 1999-12-19 21:30:01

At 04:07 PM 12/19/99 -0500, Dave Abrahams wrote:

>I've just been looking at the documentation for this. I'm not absolutely 
>clear on the motivation, but as I understand it, the problem is one I have
>always thought should be solved differently.
>
>My understanding of the motivation: provide a way to portably and compactly
>move integer types across platform boundaries.
>
>My view has always been that it shuold be treated as a streaming problem, by
>using a special kind of ostream that writes in a portable binary format
>instead of as text. A highly efficient variant would use a simple form of
>compression.

Yes, that would be very space efficient.  But not very fast if you have
lots of data such as in a database, because there has to be a call to a
(probably complex, probably non-inline) stream function for each integer
read or written.  It is actually worse that that, because there would often
first have to be a call to a manipulator to specify the length.  

The beauty of the bin_ubin.hpp classes is that underneath they are just
chars, so can be read or written in bulk.  Thus something like a B-tree
page with a thousand of these objects is read or written with a single
binary read or write.

On the other hand, these are low level classes.  Applications where maximum
binary speed and space efficiency isn't required would be better off to
just use ASCII text streams for data interchange.  

>The classes as implemented look like you have to make some assumptions about
>class layout if you want to use them for the purpose as I understand it.
>This may be OK because they're borderline PODs, but I'm not checking to see
>whether that's in fact true.

My understanding is that a compiler would actually be permitted to insert
padding bytes between bin/ubin objects in a structure, thus destroying
portability.  Use of classes like these (and earlier C language
equivalents) stretches back over 17 years, however, without problems.  Use
has included
everything from giant mainframes to small embedded systems, dozens of
operating systems, and applications both large and small. 

> Still, I don't think they are likely to be
>placed as desired in an array. Just how _are_ you supposed to use these?

The usual is to put them in a structure used for I/O:

struct BalanceRecord {
          boost::ubun24  account_number;
          boost::bin32   balance;
          ...
          } rec;

some_binary_ifstream.read( static_cast<char*>(&rec), sizeof(rec) );
...

--Beman