From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-24 10:32:42
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