From: Robert Ramey (ramey_at_[hidden])
Date: 2007-12-07 15:07:38
Edgars Irmejs wrote:
> Boost Serialization library provides a great solution for serializing
> derived classes by pointers to base classes, but I'm concerned with a
> simple use case:
> The program is being used on two computers "A" and "B" where "A" sends
> data to "B" by the means of serialization. At some upgrade of the
> program a serialized class "bus" is complemented with a derived class
> "big_bus". Only computer "A" gets the new version. I don't want the
> old version on "B" to dismiss a received "big_bus" object from "A", I
> need to convert it into a "bus" class object. It is sometimes much
> more useful to process the "big_bus" as a "bus" than not to process
> at all.
> I can assure serialization of each derivation starts with the
> serialization of the base class. I'm also ready to cope with the
> overhead of storing parent class information within the information
> about the derived classes. And it's ok if multiple inheritance is out
> of the question.
> Is there a pattern, a proposed solution to allow this dynamic
> "fallback" to base classes?
Currently the library will throw and "unregistered class" exception.
Personally, I would prefer to spend my effort in making sure this
never happens rather than trying to accomodate it in someway.
BUT, you're not me so the question remains.
I think all you need is in there.
a) Handle the thrown exception in a more elaborate way.
b) Only polymorphic base class pointer serialize their derived
classes. If you just make sure your classes don't have
any "virtual" functions and you only serialize through the
base class, there would be nothing to do.
c) You could use class versioning to recognise that
the current version is greater than the version which
was used when the application was built.
d) Already there are boost/variant and boost/optional
serializations in the library. They might be of use here.
Those are the ideas that come into my head in the
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk