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