> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost