[boost] Serialization of variant types (Was Re: Serialization Review Results)

From: Peter Petrov (piettropro_at_[hidden])
Date: 2002-12-13 11:45:08

>From: "Peter Petrov" <piettropro_at_[hidden]>
>
>>Something that I would really like to see, is the cooperation between the
>>serialization library and the dynamic_any type (developed by Alexander
>>Nasonov, not yet into Boost). More specifically, it must be possible to
>>serialize and deserialize dynamic_any's if, of course, the underlying
>>types support this and the dynamic_any is configured in a suitable way -
>>for example, to support operator<< and/or operator>>, and possibly
>>something more if necessary. This would be a very powerful mechanism,
>>allowing serialization of arbitrary data.
>
>Why don't you try to implement it with the current library?
>The package includes serialization of shared_ptr and auto_ptr
>as examples.  Also includes serialization of all stl collection
>templates.  I'm sure you could implement this in short order.
>
>Robert Ramey

It is not the same. With shared_ptr, auto_ptr and STL collections, the
underlying type or some base class of it is known at compile time. But with
any and dynamic_any, we don't know anything about the type of the actual
value until run time. We don't even know if it has a base class or not.

And unfortunately, because of the lack of a known base class, the trick with
the virtual load/save functions that you have used in the example
demo_unregistered_ptrs.cpp, is not possible in this case. The
deserialization is an obvious problem.

It surely can be built on top of the current library (which is really
extensible). But it is definitely not trivial, and I think that the
situation is too common and deserves to have good support from the
serialization library. I have some ideas which seem to fit nicely with your
current design of the library, without affecting the existing code (you
shouldn't pay for what you don't use). But they are still just ideas and I
have not yet tried to implement anything.

First, we will definitely need some set of globally unique class identifiers
(GUIDs). The set should be really "global", unlike the guids in
demo_unregistered_ptrs.cpp, which are coupled with a specific class
hierarchy. This is necessary because the (de)serialization routines for the
dynamic_any must have a way to uniquely identify an arbitrary type. To my
understanding, managing this set of GUIDs is naturally a job of the
serialization library. It should be related with the registration of types,
which as far as I understand it currently does little more than a
specialization of templates.

I find it impossible to come up with a perfect universal generic
specification of a GUID. Using integers or enums is unacceptable because it
is impossible to guarantee their uniqueness when there are more libraries
involved. Using strings is acceptable, although not space-efficient. For
reasons of speed, string values could be combined with a hash. Good
candidates are type_info::raw_name() and type_info::name(). Unfortunately,
their values are not portable between compilers.

My proposal is to add another static function to the class "serialization":

static const std::string& guid();

By default this function should return the value of typeid(T).raw_name(). It
can be overriden and the user is able to specify whatever GUIDs he wants for
his classes. Note that this will also solve Dave Harris' concern about
serialization of renamed classes.

Having this done, it's almost trivial to support serialization of arbitrary
variant types, by prefixing the actual value with the GUID. Of course, the
GUIDs can be managed outside of the serialization library, but to me it
seems that this should naturally be its responsibility, and the
"serialization" class is the perfect place for that.

Best Regards,
Peter Petrov