Re: [Boost-users] [Serialization] Questions / Comments

Subject: Re: [Boost-users] [Serialization] Questions / Comments
From: Rutger ter Borg (rutger_at_[hidden])
Date: 2009-07-16 17:08:44

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