[boost] Formal review: serialization

From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2004-04-25 15:01:47

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?

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.

> Did you try to use the library?  With what compiler?  Did you have any
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