Re: [boost] [Boost Review] Property Tree Library --canaboost::serialization expert assess interfacing options

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-04-23 12:52:43

On Sun, 23 Apr 2006 09:19:54 -0700, Robert Ramey wrote
> Jeff Garland wrote:
> > Well, the order of fields only matters in boost::serialization
> > because all the current archive classes read in order from the
> > serialized data.
> 
> I did it this way for two reasons:
> a) it was easier
> b) it supports arbitrary sized archives - they don't have to be 
> loaded all into memory.

Yep, it's the way most serialization libs work -- nothing wrong with it at all.

> >I assure you that a serialization archive can be
> > built that doesn't depend directly on order.  Essentially the archive
> > would read and parse the data into an intermediate structure
> > (property tree might be good :-) and then responds to the
> > deserialization requests using a mapped based lookup instead of
> > getting the next data from the file.
> 
> I'm surprised that no one (that I know of) hasn't done this.

Me too...

> > The same exact implementation
> > can be used to make a binding to a database buffer derived from an
> > sql command -- this also might not have the fields in the same order
> > as the object being serialized.
> 
> >Not providing support for this case
> > was one of the reasons that boost::serialization was orginally
> > rejected.
> 
> Hmm it still doesn't permit re-ordering of the data items at any 
> level - still it got accepted. Maybe I just outlasted my critics.

Not sure what you mean.  Surely if I write MyFancyArchive class I can simply
load the data and lookup on the fieldname during the load step, right?  I
agree this isn't how the current archives work, but I don't believe this
design is precluded.  Of course it requires nvp style in the object eg:

  ar & make_nvp("field1", obj.field1);

Jeff