[boost] Interest in binary serializaton library?

From: Zorba the Hutt (zorbathut_at_[hidden])
Date: 2002-06-01 17:29:15

I've been playing around with making a binary serialization library in the
same style of C++'s streams (in fact, nearly identical) and I was wondering
if there would be any interest in adding it to Boost once it's more
together. Or whether there's one already :)

For those curious about details . . .

It's designed to parallel the C++ stream hierachy (fstream becomes bfstream,
iostream becomes biostream, ifstream becomes bifstream), with the exception
that it's not templated. Since it's dealing on a byte level at all times it
seemed kind of useless. It uses the already-existing streambuf classes to do
the actual work, so adding other people's extended streams to it would be
extremely fast. I'm not having any support for formatters at the moment
(because what would they do? :P) but aside from that, just about everything
that works on C++ streams will work on these binary streams.

As for endian-ness, I'm making that an option in the .open() call - you can
choose native, bigendian, littleendian, or network byte order. I'm leaning
towards native being the default, just because people who understand why
their bytes are in the wrong order will also be able to figure out how to
change it.

Different size of datatypes will be completely ignored, in effect ;) If you
pass it a 4-byte integer, it'll write 4 bytes. If you want crossplatform
code to write the same files across different platforms with different
integer sizes, the coder should use typedefs to define 32-bit and 16-bit
datatypes, then interface with those.

I'm using the same operator<< semantics that iostream does. I'm not planning
to derive from iostream, so it'll be easy to make new operator<<'s for all
important types. I'm planning to write operator<<'s for all the basic data
types (except pointers) as well as all the STL containers, obviously calling
their target type operator<< as part of the process.

>From this basic overview, can anyone see anything wrong with this? I'm using
a combination of MSVC.NET's documentation and the C++ standard to make sure
these classes conform as much to the iostream specs as make sense.

-Zorba