[boost] serialization: registration of class types via header, or explicitly

From: John.Clayton_at_[hidden]
Date: 2005-11-22 08:24:38

Hi All,

I am trying to understand better how I can create a library of objects that can be streamed using boost::serialization (cool work btw).  I have written a program that works OK, but there's a catch - I have to explicitly register the class types on the archiver instances before serialization.  I had initially thought that the way around this was to use the following macro in the header file, just after declaring the class that will be stream-capable, e.g.:
        BOOST_CLASS_EXPORT( WatchdogPrimaryVote )

But if this is all I do (see below for what I really really have inside the header), then the write to a stream works OK, but reading back - in the same process space - throws an exception, telling me the class type is unregistered.

When I register all known message types with the archiver explicitly, things work ok.  e.g.:
    template < typename Archive >
    void registerClassTypes( Archive & ar )
    {
        ar.template register_type < WatchdogMsgBase > ( static_cast < WatchdogMsgBase * > ( 0 ) );
        ar.template register_type < WatchdogState > ( static_cast < WatchdogState * > ( 0 ) );
        ar.template register_type < WatchdogPrimaryVote
           > ( static_cast < WatchdogPrimaryVote * > ( 0 ) );
    }

I am using boost_1_33_0 on Win32 with XP and Dev Env 2003 VC 7.1 - my project is a console application that links in the message as a dynamic library.  So yes, I'm using __declspec(import/export).

I had thought that when one uses the BOOST_CLASS_EXPORT() macro, that the types we're auto-magically added/known to the archivers, because of some definitions that get created the macro itself.

Questions:
==========

- Any ideas why I would have to do this (is it a problem with __declspec(imp/exp))?
- Should I just throw away the idea of a dynamic library ang go static (it's all the same to me)?
- With .so's on *nix would I have this same issue? (or maybe that's a little too broad cos it's compiler dependant - I don't know, looking at the details of the templates makes my eyes water sometimes).

Thanks for any time that anyone has to read through all of this - sorry to include lots, I did that based on the 'more info is better' idea - although there's probably more detail I should give anyway.

John Clayton

PS:

Here's a little more detailed background, I have :
==================================================

- created a series of objects that are streamable, each derived from a common base class, using intrusive serialization

- written a series of these objects, to a std::ostream, via 
        ar & obj;

- never written an instance of the base object to the stream explicitly

- closed the std::ostream and re-opened it again (obviously as a std::istream type object)

I am reading objects from the stream like this:
        WatchdogMsgBase *ptr = 0;
        archiver & ptr;

in WatchdogPrimaryVote (derived from WatchdogMsgBase), I serialize like this:
.
.
.
    template < class Archive >
    void serialize( Archive & ar, const unsigned int version )
    {
        REGISTER_DERIVED_AND_BASE( WatchdogPrimaryVote, WatchdogMsgBase );
        ar & BOOST_SERIALIZATION_NVP( _voteType );
        ar & BOOST_SERIALIZATION_NVP( _responseType );
        ar & BOOST_SERIALIZATION_NVP( _isConnected );
        ar & BOOST_SERIALIZATION_NVP( _uniqueId );
    }
.
.
.
BOOST_CLASS_VERSION( WatchdogPrimaryVote, 1 )
BOOST_CLASS_EXPORT( WatchdogPrimaryVote )
BOOST_CLASS_TRACKING( WatchdogPrimaryVote, boost::serialization::track_never )

// end of file

and the macro expands to:
#define REGISTER_DERIVED_AND_BASE(derived, base)\
   boost::serialization::void_cast_register<derived,base>((derived *)0, (base *)0)

Thanks

John Clayton

Visit our website at http://www.ubs.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.