RE: [boost] RE: Serialization Library Review

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-11-18 07:04:40

> Let me give one example: we store parameters in a class
> 
> typedef std::map<std::string,std::string> ParameterMap
> 
> Actually the second template parameter is a more complex class, but for 
> the sake of this example above is a valid simplification. I write that 
> into XML as e.g.:
> 
> ParameterMap m;
> m["L"]="10";
> m["T"]="1.0"
> 
> gets converted into:
> 
> <PARAMETERS>
>    <PARAMETER name="L">10</PARAMETER>
>    <PARAMETER name="L">10</PARAMETER>
> </PARAMETERS>

I assume you meant:
 <PARAMETERS>
    <PARAMETER name="L">10</PARAMETER>
    <PARAMETER name="T">1.0</PARAMETER>
 </PARAMETERS>

> If instead of typdef-ing ParameterMap as a std::map, I derive 
> ParameterMap from it then I can easily write a save and load function 
> to write and read that output. Thus XML can be included.
> 
> There is however the problem that I cannot just write
> 
> for (ParameterMap::const_iterator it=m.begin();it!=m.end();++it)
>    ar << *it;
> 
> since the default serializing of a std::pair does not give my my 
> PARAMETER element above. Instead I have to write things explicitly:
> 
> for (ParameterMap::const_iterator it=m.begin();it!=m.end();++it)
>    ar << "<PARAMETER name="\"" << it->first
>     << "\">" << it->second << "</PARAMETER>\n";
> 
> and reading is more involved.

Well, if this can't be done in a general fashion so that you
don't have to be aware of the 'ParameterMap' in the archive 
code then the serialization design is broken.  That's not to
say that the XML backend might not need additional information
that is not normally supplied by the framework.  For example, a
mapping between the type info and the XML element name. 

The absolute key to the Serialization design is that the load/save
as written by the user should stay unchanged no matter what
the archive type. That is really the point of serialization -- 
to break an N*M design explosion problem.  That is, N classes 
and M formats.  If I write them all by hand it is an awful lot
of work because for each class I have to write a format 
adapter for each kind of format -- hence (2*N)*(M*2) methods.  
(The 2's come from load/save).  With serialization it is 2*(N+M) 
because the same load/save works for all M formats.  Each
format adapter (archive in this lib) encapsulates all the 
deatils of reading and writing this format.  Format adapters
tend to be difficult to write while the load/save for the
average class tends to be trivial...

> For these reasons I would not use the serialization library for XML 
> I/O. We are currently working on a simple XML I/O system to fulfill the 
> need of serialization into XML, but it cannot actually profit from the 
> serialization library. We are hesitant do not want to post it to boost, 
> even when the documentation is finished, since for now it does not 
> support Unicode (as required by XML) but just plain ASCII.
> 
> While XML output is thus clearly possible in the serialization library, 
> the library is clearly not the optimal choice if you have to write or 
> read XML

Serialization will never be the 'optimal' choice for mapping to any format.
If you only have 10 classes and 2 formats and a need to optimize then
you will be better off just writing things directly.  If you have 200
classes and 4 formats it's a different ballgame altogether...

Jeff