Robert Ramey wrote:
named-value pairs are dependent only upon <utility>. it is a "wrapper". in the library, "wrapper" is a way of attaching extra data to a datum - in his case it attaches the variable name which C++ doesn't provide a mechanism to determine. It is easy to make special purpose wrappers.
Thanks for the direction. So, given the wrappers it is possible to instantiate different code paths of the archive, to make the serialization operator behave differently? I'll look into it.
2) I would like to create an archive that speaks the Action Message Format (AMF). Although I do have trouble finding a clear distinct parsing layer in the archives, I think this is possible to do. However, perhaps you think archive/serialization should not be used in conjunction with these kinds of uses.
XML serialization is an interesting case to look at. It does use spirit to "parse" little bits of the archive. But it can't read any arbitrary xml archive into a predefined C++ structure. Of course it never could. However, we were able to generate a file following XML grammar and read back THAT SAME FILE. So the serialization library uses XML in only a very limited sense.
I see. I didn't mean arbitrary, I meant with the nodes and attributes shuffled. I.e., with a map-like interface to the serialized datums vs. a stack-based interface. I.e., in such way that the order of elements does not matter. The name in the name-value pair is then used as a key for lookup.
b) I don't think that those who desire this facility would be satisified with the result. I think they expect some sort of module which will permit a lot of editing to be read back into the C++ structure. If you think about this, this effectively means that serialization would have to handle an arbitrary xml file - and that just is not doable.
I guess I'm not looking for the arbitrary case. Serialization can already be used as a working mechanism for reading a well-crafted file that exploits exported class definitions to create a vector of arbitrary objects (which could be requests, commands, active objects, etc.). [snip] Thanks for the examples, but these were probably not what I meant. I'm looking for a bit more flexibility and customization for the archive formats. The second example I mentioned, the action message format, is more a binary serialization format.
Given how simple it is to explain what the serialization library does - it turns out to be quite a rich subject.
Indeed it is. I think the line between serialization and program options is also a thin one. Cheers, Rutger