[serialization+date_time] Serialization Review: serialization of dates
All - Since I'm the review manager I'm not doing a formal review of the library, but I thought I'd share some code and a few thoughts. If serialization is accepted users people will ask me and other library authors to provide serialization support for some of the types in their libraries. So to get a feel for the difficulty of extending serialization for new types I wrote the serialization code for gregorian::date and some example code to try it out. Of course this sort of extension is a critical aspect of the library design since everyone with a unique type will need to write serialization code. Overall I felt the docs did a pretty good job of explaining what need to be done and the code turns out to be reasonably trivial. Note that the code is more verbose than required as I did not use all of Robert's macros. Also, gregorian::date doesn't currently have a default constructor and hence it is a more challenging case (as I recall the first submission of the serialization lib required default constructors). When programming with dates and times putting them into collections is quite common. Fortunately, one of the most impressive aspects of the current serialization library is the ability to handle stl collections. So I was glad to find (as I expected) that by enabling the serialization of gregorian::date serialization of collections of date's comes along for free. I've attached the code and the serialized file for your reading enjoyment :-) Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
If serialization is accepted users people will ask me and other library authors to provide serialization support for some of the types in their libraries.
It should be considered where to put all such code. 'boost/serialization/boost' directoy could be used for all Boost libraries. One place is better than to have bits scattered accross source tree. /Pavel
On Sun, 25 Apr 2004 09:55:21 +0200, Pavel Vozenilek wrote
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
If serialization is accepted users people will ask me and other library authors to provide serialization support for some of the types in their libraries.
It should be considered where to put all such code.
Yep.
'boost/serialization/boost' directoy could be used for all Boost libraries. One place is better than to have bits scattered accross source tree.
Well, I think it belongs in the library supplying the data type not in serialization. Few reasons for this... 1) I don't want serialization depending on every library in boost -- the other way around makes more sense. 2) 'User' serialization code should be located with the types being serialized. Point is that if the type internals change, maintenance may be required. If the serialization code is off in some other directory it is easy to forget. This also should be the way non-boost code is done -- we should show the way. 3) If the developer chooses to add serialization internally in their class then the code has to be in the client library. I don't think we should force boost developers to use the external serialization like I posted. So for the particular case I posted I was planning on putting this code in boost/date_time/gregorian/greg_serialize.hpp Time could would go into boost/date_time/posix_time/time_serialize.hpp Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes
'boost/serialization/boost' directoy could be used for all Boost libraries. One place is better than to have bits scattered accross source tree.
Well, I think it belongs in the library supplying the data type not in serialization. Few reasons for this... 1) I don't want serialization depending on every library in boost -- the other way around makes more sense.
It is not that Serialization library would depend on others. It is just place to put headers.
3) If the developer chooses to add serialization internally in their class then the code has to be in the client library. I don't think we should force boost developers to use the external serialization like I posted.
Yes.
So for the particular case I posted I was planning on putting this code in boost/date_time/gregorian/greg_serialize.hpp
Time could would go into boost/date_time/posix_time/time_serialize.hpp
Current naming conventions are like: boost/serialization/vector.hpp for <vector>. Maybe name boost/date_time/gregorian/serialization/... would fit better. Whatever, it should be easy for user to find of whether or not library supports serialization. Maybe some publicly editable page in docs is solution. /Pavel
On Sun, 25 Apr 2004 19:29:39 +0200, Pavel Vozenilek wrote
"Jeff Garland" <jeff@crystalclearsoftware.com> writes
'boost/serialization/boost' directoy could be used for all Boost libraries. One place is better than to have bits scattered accross source tree.
Well, I think it belongs in the library supplying the data type not in serialization. Few reasons for this... 1) I don't want serialization depending on every library in boost -- the other way around makes more sense.
It is not that Serialization library would depend on others. It is just place to put headers.
Well, I guess since it is all templates the dependency isn't real strong but I still don't like code for other libraries under the serialization tree. Also, this approach prevents libraries from using non-template code -- although maybe that doesn't matter since all the serialization intefaces are templatized. Perhaps pending the outcome of the polymorphic archive addition.
3) If the developer chooses to add serialization internally in their class then the code has to be in the client library. I don't think we should force boost developers to use the external serialization like I posted.
Yes.
So if most developers do this and few don't then we will have an uneven solution for users. Sometimes they will need to go to a path under serialization and sometimes they won't. I think always putting that code with the client library makes more sense. If it requires an additional header to be included that should be documented in the downstream library.
So for the particular case I posted I was planning on putting this code in boost/date_time/gregorian/greg_serialize.hpp
Time could would go into boost/date_time/posix_time/time_serialize.hpp
Current naming conventions are like: boost/serialization/vector.hpp for <vector>.
Sure, but that's because boost doesn't have a way to change the standard library headers. If serialization was part of the standard I would expect to get the ability to serialize just by including <vector>. Of course there would still be some other include like <archive> to get the archive headers.
Maybe name boost/date_time/gregorian/serialization/... would fit better.
I think having another directory level just for one serialize.hpp is a bit much. BTW, I forgot to say that I was assuming that boost/date_time/gregorian/gregorian.hpp boost/date_time/posix_time/posix_time.hpp which are the 'include everything' files for date_time will also include the serialization code so that no extra work will be required for most users.
Whatever, it should be easy for user to find of whether or not library supports serialization. Maybe some publicly editable page in docs is solution.
I was assuming I would need to introduce documentation in date_time that shows all the serializeable types. An example would also be nice. I would also like to see a table in the serialization docs that lists the boost libraries that support serialization. Probably just a simple table that points off to docs in the other libraries. I think the combination of these 2 things should make it easy for users to find what is supported. Jeff
participants (2)
-
Jeff Garland -
Pavel Vozenilek