From: Michael D. Crawford (crawford_at_[hidden])
Date: 2000-11-17 22:56:31
> 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'd like to suggest you have a look at the ZStream classes in the ZooLib
cross-platform application framework. It's at
and it's released under the MIT License (the same license XFree86 uses I
I think most of what is in Andy Green's stream implementation could be
lifted out of ZooLib without having to take the rest with it.
I seem to recall that Andy had << and >> operators in his streams until
just before releasing ZooLib, but took it out for some reason. Instead
he has methods with explict names like "WriteInt8" and "WriteInt16" and
so on. But it's a simple matter to write nonmember functions for
operator<< and operator >> that do what you need.
I used ZooLib's streams in a recent project to dump formatted XML files
from a Document Object Model tree built with the Xerces XML library (the
C++ version) which you can get from http://xml.apache.org - I based it
on their DOMPrint sample code, but with my code I could, if the urge
possessed me, format my XML into files, network sockets, filters into
Base64 encoding or what have you.
I believe ZooLib generally assumes you're going to be in big-endian byte
order, which might cause a pretty tiny performance loss on x86 but makes
your file formats a lot easier to read in a hex editor.
It really works pretty good.
-- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com crawford_at_[hidden] Tilting at Windmills for a Better Tomorrow.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk