[boost] [serialization] Dealing with any tainted types.

Subject: [boost] [serialization] Dealing with any tainted types.
From: David Sankel (camior_at_[hidden])
Date: 2011-01-13 15:25:29

The serialization library allows for the painless serialization of most data
types and even polymorphic types like variants and vectors.

There is one type, however, that doesn't have a serialize function that
makes sense. That type is any. It is easy to see that if we make an any
serialize function, we're going to need to make some assumptions at least
about which subset of types it might contain.

I have a complex algebraic datatype, lets call it C, that has a member (that
has a member...) of type T. T is "tainted" with a member of type any. I'm
looking at the possible ways to serialize C with boost.serialization. We can
know, at runtime, which subset of types the any member of T can contain and
how to serialize each of those types. Lets call the dictionary type that has
that information D.

Here are the options I've come up with so far...

Option 1:

Make some global variable of type D, called d. Before calling any
serialization of C, I ensure d has the correct value. The serialize function
for T uses d to figure out how to serialize the any member.

This option would certainly work, but I'm using a global variable as a
workaround of the fact that I cannot add arguments to T's serialize
function. No points for beauty here.

Option 2:

Instead of serializing a value of type C, serialize a value of type "struct
CWithDict { C c; D d; }". In this serialization function I can use d
whenever I need.

Unfortunately the contents of this serialize function would need to
duplicate most of the functionality of boost.serialize in the first place
since T is buried deep within C's structure. Although this option works, it
requires rewriting a bunch of serialize which isn't attractive.

Option 3:

Make an archive wrapper:

template< typename Archive >
struct DArchive
{
  Archive a;
  D d;
};

DArchive would model the Archive concept by forwarding functionality to a.
However, the T serialize function could access DArchive's d member for
serialization of the any.

This would solve the problem at the expense of extending the meaning of
Archive a bit. It seems pretty elegant to me.

So, that's what I've come up with. I'm interested in comments. Does anyone
know of a better way to do this? Could this possibly lead to a general
mechanism for similar problems?

TIA,

David

-- 
David Sankel
Sankel Software
www.sankelsoftware.com