From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-24 05:22:50
Robert Ramey wrote:
> I'm completely at loss how to serialize classes which use the pimpl idiom.
>>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
> 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"
Yes, that's the problem for plug-ins, too.
> 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.
I think this will be okay for me.
> 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
> this would maintain the same archive interface but would
> dispatch to derived classes through the normal vtable
> dispatch mechanism.
I was thinking about this same solution yesterday evening. It sure decreases
performance, but nothing's for free.
> 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.
I seems possible. The 'virtual_archive' will call virtual functions for
saving built-in types and serialization::save for all the rest? Is the
"vsave" family of method what you have in mind?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk