Boost logo

Boost :

From: quendezus (quendez_at_[hidden])
Date: 2002-03-01 05:12:44

--- In boost_at_y..., "rameysb" <ramey_at_r...> wrote:
> Permit me to attempt to summarize the recent discussion:
> ...
> b) implementation of archives in terms of istream/ostream. no
> registered objections.

I am a bit uncomfortable with this iarchive/oarchive system. In the
previous discussion about persistence on boost, we had a hard debate
about what should be the archive class. An idea was that it could be
a template parameter.

> I would propose that two new classes be created - say
> binary_iarchive
> and binary_oarchive that would use binary rather than text
> This would:
> i) not be very hard to do. Only a small part of the iarchive and
> oarchive classes are particular to text/binary i/o. These
> sections could be moved to derived classes.
> ii) It would mean that save/load functions would suffer no
> iii) programs could select binary/text archives at runtime by
> choosing which variation of archive to use.

I think a binary archive is necessary. But what next? What about a
XDR archive? Maybe it would be possible to let the user decide what
the type of the archive is. After all, the framework does not use the
archive a lot: it mainly passes it from the caller to the save/load
functions. For example:


// Framework (namespace boost)

template < class Archive, class T >
void serialize( Archive& a, const T& t ) { ... }


// User code

#include "binary_stream.h"

class Plane { ... };

void save( binary_stream& s, const Plane& p ) { ... }

int main( )
        Plane p;
        binary_stream s( "save.dat" );
        boost::serialize( s, p );


An advantage of this mechanism would be the separation between the
serialization framework and the archive/stream part. Different
streams or archives could be developed and plugged into the
framework. And the debate about text vs. binary would be less
important (I think this debate is endless because the choice depends
of the usage).

Some problems to resolve in such a system:
1- Sometimes the framework needs to write some data (type
description, etc.) into the stream/archive.
2- Sometimes the framework may need to store temporary data into the
stream/archive object (for deserialization of cyclic graphs for
So maybe the archive type should have some minimal requirement, or a
type trait should be provided.


Boost list run by bdawes at, gregod at, cpdaniel at, john at