[boost] Re: Serialization Library Review

From: Yitzhak Sapir (yitzhaks_at_[hidden])
Date: 2002-11-18 08:30:14

It is not clear to me, but it seems like the deadline was extended.  Dave Abrahams asked Thomas, and he wrote back a simple message.  It would have been nicer if there was a general announcement to that end, in my opinion.

In any case, I have MSVC 6.5, and based on the discussions it seems that this compiler is not supported.  Is this the case?

I have some experience with serialization.  I have myself tried to write a "serialization library" but it is not yet even at the point that I can post it here to get some preliminary feedback.  It does support multiple formats in an independent way of the classes, and I have written a yaml (http://www.yaml.org) writer class for the system, mainly to have some text output format and also to show that complex serialization was possible.  I also have a reflection system that I intend to add.  The point of this is that in my view, serialization is a much bigger issue than breaking the N*M problem.  Breaking the N*M problem is one issue.  Breaking up containers is another.  Proper serialization of integers between one system and another is yet another.  Reflection is yet another.  And pointer serialization is another.  Then some might want ready-made serializers for their pet format (text/yaml/xml/xdr/hdf5/etc).  And others would like versioning.  Lots of issues, which is in my opinion the reason why a serializat
ion system is so hard to create.  There are so many demands, that saying "serialization" does not fulfill these needs for everyone.  It fulfills the needs of some people, say 25%.  But any system that addresses one of these issues will only get 25% support.  A wiser approach would be to address each one of these separately, in a separate library.

In this case, this means taking out the entire pointer system into a separate class.  This in my opinion is a necessary need anyway.  Just like an allocator is a separate class for an STL container, so too a pointer-system is a separate class for a serialization library.  This would allow using the same pointer-system object for both the reading and writing.  And it would enable users to use the functionality in other serialization systems that might be better fitted for their needs, such as an XML system.  Robert has spent a lot of time in verifying the pointer system, that I cannot say that I could criticize one approach or another that he took.  But right now, it is my understanding that this pointer serialization is interleaved with the main serialization system.  This prevents one from reusing the functionality for an XML I/O system, or even for both input and output.  (Please correct me if I'm wrong).  I think it would be much better if this "serialization system" was renamed "pointer serialization fac
ility."  The main facility of the library would be the pointer class that contains the logic that is currently interleaved.  The rest of the code, which gives users ready-made code for some of the above-mentioned serialization needs, could be provided as an example code of how such a pointer facility is usable in real-code.  It thus provides the best of all worlds -- a library that is strong in what it claims to support, and example code to allow users serialization facilities without the need to rebuild the wheel, if it's not necessary.  (For XML and other needs, it might be necessary, but for some needs it won't be).

I think taking out the pointer facility into a separate class would be better design.  By this I mean, that register_type<> and the logic for identifying and maintaining pointers would be in a separate class from the archive.  The archive would hold an instance of this class (given in the constructor), and use member functions of this container class to determine what to do when it encounters a new pointer/alias.  But it seems to me this is not the case yet (again, correct me if I'm wrong).  Until this is done, my vote is no.  If this was done and I could test the code on MSVC6.5, my vote would probably be yes.