This raises the question of what to do in the following circumstances. a) person X requires serialization for library Y b) It doesn't currently exist and the current library maintainer has not made it. b) so he writes it and likes it. c) he wants to submit it to boost Questions that arise: a) His addition will included a header - where should it go. i) My current preference is boost/Y/serialization.hpp ii) On the otherhand, the ones I personally did - shared_ptr and some others have been put into boost/serialization/Y.hpp. This also applies to the STL serialization - since there is not boost/stll/... in any case. b) He should include tests. But where should he put them? The current situation mirror that of the above. The current method of making the library maintainer responsable for making tests pass wouldn't attribute the responsablity to the appropriate party c) Is any documentation necessary? - where should it go? d) Should such a contribution be subject to some sort of review. This last is interesting to me. In the past I received an implementation of serialization for boost::variant. This is something I always wanted so I included it. Then tests showed that the implementation wouldn't work for borland, msvc 6.x and maybe others. The there was the "requirement, that the implementation depend only on the public interface. The maintainer of boost::variant didn't participate. The final implementation wasn't quite as efficient as I would have liked but I didn't want to start a drum beat to tweak boost::variant. Adjusting the implementation to be as widely applicable as other serialization implementation - ie older compilers - turned out to be more time than I anticipated. So I would like to see some "fixed points" be enforced - that is, that it meets the requirements that other serialization implementations in the library maintain. Basically serialization for a library Y sort of lies in the intersection of the serialization library and library Y. Robert Ramey Martin Slater wrote:
library contains code to serialize "shared_ptr" types. Should the Serialization library contain similar code for every potential Boost type, so should each type include the code?
If the latter is the answer, then does:
class my_type { friend class ::boost::serialization::access; //... };
I just ran into this again when I needed to serialize a boost::dynamic_bitset and with porting our codebase over to use 1.33 bringing across the modification I made to boost::filesystem::path for serialization. If there is a chance that these will get incorporated into cvs I will go to the effort of writing and configuring test cases for them and submit them (I did submit sode and tests a long time ago for filesystem::path but unfortuantly they never made it in so I'm reluctant to do more unless there is willing by the library authors to have them). It seems there should be a concerted effort to get all of boost being able to serialise out of the box as it leaves the library as a whole feeling somewhat disjointed. I may have some free time in the near future so I could be persuaded to go through implementing / incorpating existing patches for serialisation for other boost libraries.
cheers
Martin