[boost] Re: Serialization Library Review

From: Alberto Barbati (abarbati_at_[hidden])
Date: 2002-11-14 14:18:24

Robert Ramey wrote:
> Alberto Barbati wrote
>>Please note that the "registry" class I described *does not* attempt to 
>>solve the broader issue of UUIDs I read about in the discussion between 
>>you and Vladimir. My proposal is just a way to separate the 
>>"registration" part from the "serialization" into two different 
>>compontents. Still the classes will be matched according to their 
>>registration order, as it happens now. I am ready to discuss the 
>>opportunity and/or usefulness of this approach, but I don't see the 
>>reason why this could not be done.
> 
> 
> I considered this approach and found the following problem
> 

It seems from the objections you raise that I did not explain myself 
well enough. Before answering to them, I think a code snippet would 
help. Consider this code, that uses current implementation:

---begin code

   std::ofstream s("...");
   boost::oarchive a(s);
   a.register_type<t1>();
   a.register_type<t2>();
   a.register_type<t3>();
   a.register_type<t4>();

   // do serialization

---end code

What I am suggesting is to allow, possibly in addition to that form, the 
following form:

---begin code

   boost::serialization_registry  r;
   r.register_type<t1>();
   r.register_type<t2>();
   r.register_type<t3>();
   r.register_type<t4>();

   std::ofstream s("...");
   boost::oarchive a(s, r); // in the body of the constructor an
                            // equivalent of register_type()
                            // is immediately called 4 times
   // do serialization

---end code

I am *not* suggesting to change in *any way* the serialization process. 
The purpose of serialization_registry is just to allow for a finer 
granularity of responsibilities.

 > a) register all the types in the global collection in the archive.
 > bad idea - this would require that the reading program register
 > all the types of the writing program.  An intolerable requirement

With my approach you are going to register the same types you would 
register anyway. Not one less, not one more. Why would it be intolerable?

 > b) register types as needed as the library is written
 > wouldn't work - on loading, we wouldn't know which types to register
 > c) after creating the archive, append a "registration file"  on loading,
 > process the "registration file first. In my view this cure is worse
 > than the disease.

The types are going to be physically output in exactly the same way as 
it's being done by current implementation. So this two objections do not 
apply.

So you may be wondering, what's the point in having this registry class? 
There are two main advantages:

1) the module that sets up the registry can be distinct from the one 
that effectively performs the serialization. This can solve a lot of 
dependency issues.

2) the registration can be done in *one* place for *both* input and 
output. With current implementation, the registration code will be 
duplicated and duplication is always a bad thing. Imagine yourself 
trying to keep two (possibly very) long lists of register_type calls 
synchronized.

> I'm still at a loss.  Aside from addressing the "classic" above, what exactly
> do you recommend I do?  How about if I change the wording to specify
> that the library supports wide streams and leave unicode out of it?

Yes, it all boils down to change the wording as you said: you just can't 
mention Unicode. I got a little carried away because I'm working on the 
subject and I'm having a hard time getting people aware of the issue. I 
apologize for that.

>>On a different topic, I found a portability issue. The current 
>>implementation record in the archives the size of the basic types int, 
>>long, float and double. This gives you a *false* sense of security that 
>>the "writing" and "reading" platform agree on the type size.
> 
> 
> this is for the native binary archive which is explicitly described as
> being non-portable.  It was included because some users felt it
> would be more efficient.  It has no pretensions at all to portability.
> Knowing that some one will ignore this admonishment and
> try to move such a binary to another machine architecture, 
> Included free detection so that it would crash in a more 
> graceful manner.

All right, but still the size_t issue with read_string/write_string is a 
bug, as it does not involve cross-platform. With current implementation 
a program will fail reading its own serialized strings on a least one 
plaform (i64).

Alberto Barbati