Re: [boost] suggestion on Serialization Library

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-04-15 13:25:33

Allen Yao wrote:

> It is not very convenient for me to use macros like
> BOOST_SERIALIZATION_SPLIT_FREE, BOOST_SERIALIZATION_SPLIT_MEMBER to deal 
> with splitted load/save functions.

Permit me to re-state your suggestion in order to test my understanding of
it.

Similar to the manner which we have created other serialization traits such
as boost::serialization::version<T> create another one such as

boost::serialization::split<T>

Whose default implementation would return false.

Please correct me if I've misunderstood this.

It's a worthy idea.  I'm not saying I'm convinced it's a good idea but
certainly worthy of consideration.  Here is my assessment.

Currently to split serialize member function into save/load one uses

template<class Archive>
void serialize(
    Archive & ar,
    const unsigned int file_version 
){
    boost::serialization::split_member(ar, *this, file_version);
}

Or equivalently:

BOOST_SERIALIZATION_SPLIT_MEMBER()

With your suggestion this would change to:

namespace boost { 
namespace serialization {

struct split<my_class>
{
    typedef mpl::false_ type;
    BOOST_STATIC_CONSTANT(bool, value = split::type::value);
};

} // namespace serialization
} // namespace boost

Or in line with the other serialization traits:

BOOST_SERIALIZATION_SPLIT (my_class

So

a) I don't see what would be gained as far as convenience, utility, and
transparency compared to the current system.
b) It would entail significant effort to implement and make the internals of
the serialization library even more elaborate than they already are.
c) It would require more documentation than the current system.

> Additionally, when dealing with load/save functions of template class,
> these macros help little. Users also have to read and understand what 
> these macros actually do and write their own serialize function to call 
> split_free or split_member accordingly.

I don't think this change would help that situation.

> I suggest that these implementation details on how the serialization
> library determine to use single serialize function or splitted load/save 
> functions should be totally encapsulated and hidden behind the scene.

This is widely held point of view that I don't always agree with. Sometimes
hiding too much gives the illusion of ease of use but in fact introduces
modal behavior which makes the operation hard to understand.  In the worst
cases it introduces a compile time global variable with compile time
side-effects that are hard to trace back to the trait setting. So, I'm more
wary about using traits than other people seem to be.

> Am I missing something?

I don't think you're missing anything.  It would be possible to implement
such an additional trait.  We just disagree on whether it's a good idea.
That's all.

Robert Ramey