Re:[boost] [serialization] serialization and pimpl

From: Robert Ramey (ramey_at_[hidden])
Date: 2003-10-23 12:09:23

I'm completely at loss how to serialize classes which use the pimpl idiom. 
>What I have is:

>    class BlockFormula {
>    public:
        [snip]
>   private:
>        struct data;
>       boost::scoped_ptr<data> m_data;        
>    };

>The "data" class is defined in cpp file. I can't write serialization method of 
>the form:

>    template<class Archive>
>    void serialize(Archive& ar, unsigned version)
>    {
>        ar & *m_data;
 >   }

>since "data" is incomplete type at the point where this "serialization" is 
>seen. I'd rather not hardcode the type of archieve, as in

>    void serialize(boost::archive::text_oarchive& ar, unsigned version);
>    // definition in cpp file, where "data" definition is visible.

>So, what's the solution?

This is a very interesting question.  It never came up with previous version
of the library reviewed last november because that implementation used
virtual functions.  In this case serialization could be kept in libraries as
there was no "Archive" template parameter.

I moved to a templated version for a couple of reasons:

a) Its noticebly faster.
b) I was going crazy trying to keep up with all variations of primitive types
supported by different compilers.
c) It started as an experiment to see what would happen.  I came to 
prefer it.

However, it created two issues.
a) the one you describe here.
b) related ones if one wants to create a system for "plug-ins" similar
to Microsofts "COM"

First simple solution.

separt serialization in a separt module - presumably already done
as part of the pimpl implementation.

Instantiate templates for all 5 currently archives.  Make sure that
compile granularity is set properly or that the templated
code is included in 5 separte modules.

Make sure linker is set to exclude modules not referred to.  This
can be done by leaving the modules described above in a
separate library.

This will work well and provide maximum perfomrance.  It can't be
used to support a system of plug-ins whereby serialization is
applied to all archives that meet the interface - including
archive implementations yet to be written.

Second more involved solution.

It is possible to create another archive based on virtual functions.
suppose we call it

virtual_archive

this would maintain the same archive interface but would
dispatch to derived classes through the normal vtable 
dispatch mechanism.  specific archives would be 
derived from this.  Plug in libraries would be compiled
against this header.  So in addition to the curent template
based system whereby much of the work is done
at compile time, we would have the option of using
the virtual interface for situations were its convenient
or necessary.

Note that I personally have no plans to write such a
virtual_archive but I would be pleased to support
anyone who wants to.   I believe the system would
currently support the construction of such a virtual
archive with not changes to the current code.

Robert Ramey