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

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2000-11-17 21:56:32

I think that the entire C++ stream mechanism should be extended to 
'binary'  or if you prefer, non-character-formatted streams.  That this was 
overlooked seems like a HUGE hole in the design.  Then we could use the 
normal (overloaded "<<" and ">>" operators).  Further, rather than worrying 
about big/little endian in everyone's program, perhaps we should define a 
further mechanism which standardizes on the byte ordering in the file.

I note that there IS a standard ordering for network transmission, and that 
is big-endian (sorry, Intel, you lose).

To this end, I've written some _very small_ classes/templates which 
implement (at least on VC++) binary file stream (bfstream) and a network 
ordered stream (netstream).  It is unfortunate that one cannot simply use 
"<<" or ">>" with an arbitrary class/struct, but must overload the 
operator(s) and read/write each 'element' individually. .... e.g.

struct abc
   {
         short x;
         int y;
         long z;
         float w;
         double v;

         friend netstream& operator << (netstream& towhere, const abc& us)
         {
                 return towhere << us.x << us.y << us.z << us.w << us.v;
         }
};

in some senses this can be a real pain.  But I've got a program that needs 
to share a real file with a Mac (big-endian) and this is working for me.

Note that the class netstream could be essentially 'empty' for systems 
which are already big-endian. (we're using typedef to make them the same)

I would certainly like to see this pursued, since I believe identifying the 
stream with the characteristics (dare I say 'locale') would then move all 
the funny stuff OUT of the rest of the program.

At Friday 00/11/17 15:02, you wrote:
>At 11:29 AM 11/16/2000 -0500, Beman Dawes wrote:
>
>  > ...
>  >
>  >Still other people viewed the need in terms of operations on
>  >streams, without a need for actual objects.
>  >
>  > ...
>  >
>  >It would be really nice if someone good at sifting through disparate
>  >requirements would put together a proposal broad enough to meet multiple
>  >people's needs but narrow enough not to focus on what is basically a
>pretty
>  >simple need.
>
>
>The internal objects Darin and I have discussed are really, really
>important when you need them.  But preserving legacy code and/or doing
>ultra high speed bulk I/O are esoteric compared to just stream reading or
>writing external data in a portable format.
>
>So in thinking about this further, I realize that for boost the first
>priority should be portable external format integer (and other data types)
>operations on streams.  They should include fixed length formats, but also
>(per Dave's suggestion) variable length data.
>
>What would (the fixed length flavor) such functionality look like?
>
>      int_least32_t xport_int_read4( istream & source );
>      uint_least32_t xport_uint_read4( istream & source );
>      int_least32_t xport_int_read4_little_endian( istream & source );
>      uint_least32_t xport_uint_read4_little_endian( istream & source );
>
>      void xport_int_write4( ostream & target, int_least32_t source );
>      void xport_uint_write4( ostream & target, uint_least32_t source );
>      void xport_int_write4_little_endian( ostream & target, int_least32_t
>source );
>      void xport_uint_write4_little_endian( ostream & target, uint_least32_t
>source );
>
>That doesn't seem very inspired.  Anyone have a better way?
>
>--Beman
>
>
>
>

Victor A. Wagner, Jr.
Secretary, Wyoming Libertarian Party
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
               "There oughta be a law"