Jeff Garland wrote:
On Sun, 23 Apr 2006 11:01:10 -0400, Eugene Talagrand wrote
Just a note, type tracking can be disabled in the case you described and version tags can be disabled in general. In this case, hand- editing becomes feasible: boost::serialization XML archives are what I currently use for config files, though my needs may be more limited than most. You're right that the order of fields matters in boost::serialization, but the order of tags does matter in XML in general.
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.
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.
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. Robert Ramey