I was not involved in the original review.
Do you think the library should be accepted as a Boost library?
Yes.
What is your evaluation of the design?
The design, from a usage standpoint is excellent. Coming from the MFC world, boost::serialization far surpasses MFC's in usability and flexibility. Particularly notable are: no need for a common base class, a single serialize method used both for input/output. The only problem I see is that programming errors in some cases can be difficult track down, but no more so than with any template intensive library. While the current methods for Free Functions and Splitting save/load methods are certainly understandable and work. It would be nice to be able (partial)specialize the "serialize" function base on its IO type. It would also be nice to utilize enable_if to generate different code when the serialize function is instantiated for input/output archives. This would allow compile time constructs similar to mfc's runtime Ar.IsLoad().
What is your evaluation of the implementation?
I've been using the serialization library since version 13. All previous version bugs/issues have been cleared up with version 18. I've been able to remove all workarounds from my code, in particular dealing with support of multiple archive types in a single translation unit including binary, text and xml. Performance is more than adequate for my purposes. My application uses binary serialization to implement drag/drop. On a 3 year old 2GHz pc, a pair of save/loads of a ~2MB including graphical updates takes less than 2 seconds. I have only briefly viewed library source code when finding workarounds in previous versions. Others here are much more qualified to render a verdict in this regard.
What is your evaluation of the documentation?
The documentation allowed me to add serialization to my application without needing to look at header/implementation files. Though, I'm sure I carry some context from having worked with MFC serialization. One misleading aspect IMO is with the Non-Intrusive Version example. The example implies that you would need access to the data members. I think an example of what to do when you don't have access to the data members is needed. For example, how would one serialize a boost::filesystem::path object. namespace boost { namespace serialization { template<class Archive> void save( Archive & ar, const boost::filesystem::path & t, unsigned int version ) { std::string lPathString( t.native_file_string() ); ar << make_nvp( "PathString", lPathString ); } template<class Archive> void load( Archive & ar, boost::filesystem::path & t, unsigned int version ) { std::string lPathString; ar >> make_nvp( "PathString", lPathString ); t = boost::filesystem::path( lPathString, boost::filesystem::native ); } } } BOOST_SERIALIZATION_SPLIT_FREE( boost::filesystem::path ) I'm sure this could be improved upon, but without it, there is a danger that many will think - "can't be used for my application". Seeing an examples like this makes it a little easier to remember that the template functions need to be defined in the boost::serialization namespace.
What is your evaluation of the potential usefulness of the library?
Did you try to use the library? With what compiler? Did you have any
I've always considered serialization to be a major element missing from C++. Nearly every application uses some method of custom serialization today. I've saved 100's of hours already in using boost::serialization rather than spinning custom file formats or implementing connections to DBMS systems to store/retrieve data. problems? Yes, with VC71. As stated above, all problems with versions previous to version 18 have been corrected. One, recent problem is an access violation when loading a saved shared_ptr(NULL).
How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
Applied in an actual development project over the last several months.
Are you knowledgeable about the problem domain?
I've some experience with MFC serialization. Thanks for a great library! ----------------- Jeff Flinn Applied Dynamics, International