using cereal and boost serialisation in the same program

Question

We currently have a system that uses a lot of boost serialisation to store data. We are looking to migrate away from this, to using cereal instead.

However, it is very unlikely that we will be able to completely migrate all serialised objects. At the very least, we will have to be able to de-serialise old version of the data.

Is it possible to use both boost and cereal to serialise the same object, preferably without having to write the serialisation function twice?

An example of our code is:

class Base
{
public:
    std::string m_VarA;
    std::string m_VarB

    template<class Archive>
    void serialize(Archive & rArchive, const unsigned int nVersion)
    {
        rArchive & BOOST_SERIALIZATION_NVP(m_VarA);
        rArchive & BOOST_SERIALIZATION_NVP(m_VarB);
    }
};

class Derived : public Base
{
friend class boost::serialization::access;
public:
    std::bitset<32> m_Flags;
    template<class Archive>
    void serialize(Archive & rArchive, const unsigned int nVersion)
    {
        rArchive & BOOST_SERIALIZATION_BASE_OBJECT_NVP(Base); 
        rArchive & BOOST_SERIALIZATION_NVP(m_Flags);        
    }    
};

std::ostringstream stream;
Derived var;
{
    boost::archive::xml_oarchive rArchive(stream);
    rArchive & boost::serialization::make_nvp("Configuration", var);
}

I don't think we have anything much more complicated than this.

Answer 1

I'll go out on a limb and say "Yes".

The libraries have similarity, but if they don't coexist that would be BUG in either or both libraries.

You don't show ANY code, so we don't know ANYTHING about how you organized your serialization code.

For any approach I can envision migration paths.

The most important thing to realize is that the actual serialization code needs only be visible at the point where serialization occurs. If you limit that to TU and make all the functions involved in it file-static, you'll be safe from the sharks¹.

Obviously, you'll be better off if the serialization code was non-intrusive². But even if you do, just make the intrusive method relay to free functions that can be file-static.

Holy Grail: Unified Serialization Functions

This would require more work, obviously, but seems doable with a modicum of meta programming. From a quick look it looks like it's easier to implement Boost-serializability from existing Cerial serialize functions, but I guess that's tough luck.

---

¹ sharks like ambiguous overloads or ODR violations

² /ɪnˈtruːsɪv/ adjective 1. causing disruption or annoyance...