From: Robert Ramey (ramey_at_[hidden])
Date: 2004-04-04 14:00:45
Anatoli Tubman wrote:
>Robert Ramey wrote:
>> I briefly considered this approach. I imagined that upon archive
>> creation the XML input could be parsed into a node tree. (insert plug
>> for spirit
>> here) The load_override function would be altered to search the
>> correct part of the tree. So this would work and be pretty clean.
>> I'm sure other approaches such as using SAX or DOM to parse the tree
would work as well.
>> Maybe there's another way I never thought of.
>> The main reason I rejected the idea was that I didn't see it working
>> with arbitrarily size streams. I envision serialization being used with
>> much larger then available memory. This suggested to me an "on the fly"
>> loader rather than a "pre-loaded".
>Loading the entire archive is not necessary. The other approach is to
>acquire a *description* of the data structure being deserialized, and
>process the XML stream sequentially. That is, operator<< does not do
>deserialization by itself, but inserts a member *descriptor* into a map.
>When all data members are collected in this fashion, they are deserialized
>as corresponding tags come in.
>IOW one needs random access to *either* the data stream *or* to the data
>structure being deserialized. Data streams are too big, so we should choose
>data structures instead.
>One doesn't need the entire tree of data structures either, only the node
>currently being processed, because descendants changing parent nodes are
I don't see how to do this while keeping archive and serialization
>This works because a typical class is much smaller than a typical data
>stream, which usually contains many instances of the same class.
>I have some experience with one (pre-XML, pre-C++) serialization library
>that does (approximately) just that. It uses a custom tagged format, but
>there's no reason why it shouldn't work with XML and C++.
My focus was finding the most expedient and efficient way to use XML format
with the rest of the serialization library. In the course of investigating
my options, I had occasion to look more deeply into XML. One thing that
occurred to me was the possibility of making an archive implementation which
generated an XML schema rather than the XML data. This would generate and
XML data schema either in parallel with the XML data archive or as a
separate operation. An XML tagged input implementation might make use this
as well. I would guess others might find a use for such a schema that would
automatically be in sync with the program code that generated the data.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk