Re: [Boost-users] [serialization][1.42.0] gcc(4.01)/xcode(3.1.2)failure to register type

Subject: Re: [Boost-users] [serialization][1.42.0] gcc(4.01)/xcode(3.1.2)failure to register type
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-05-05 13:06:32

Robert Ramey wrote:

I woke up last night and remembered how I dealt with this in one of the 
examples.

Suppose you've compiled everything into a static library X.

There is a header b.hpp which looks like:

class derived : public base {
    ...
    template<class Archive>
    void serialize(Archive & ar, const unsigned int version);
};

and X will contain a b.cpp file which looks like

#include <boost/archive/text_oarchive.hpp>
#include <boost/archive/text_oarchive.hpp>
... // other archives

template<class Archive>
void serialize(Archive & ar, const unsigned int version){
    ar & ...
}

// explicit instantiation
template void derived::serialize(boost::archive::text_oarchive & ar, const 
unsigned int version);
template void derived::serialize(boost::archive::text_iarchive & ar, const 
unsigned int version);
...

Now we have program A linked to library X.  If A only serializes through a 
pointer to the class "base"
then the code in b.cpp isn't linked in.  The easiest way to handle this is 
to NOT put b.cpp into
library X but rather link it in explicitly into program A.  So the make for 
program A looks like

A.exe : A.obj b.obj X.lib

In effect, the link specification becomes the equivalent "export 
registration".

The only way this will break down is if the linker is too smart for our own 
good.

If you want a finer granularity, you can slightly reorganize code so that 
you have

b_text.cpp, b_binary, etc

Or use a compile time switch to indicate which archives you want generated 
like

c++ b.cpp -DARCHIVE=text_iarchive ...

or just use the polymorphic archive for everything there are tested demos 
for doing this.

To summarize, I believe that explicitly including modules with instantiating 
code will be
the equivalent to "export registration" since these modules include the 
static singletons
whose pre-main construction makes the required types accessible to the 
system.

I think this is the best way to handle this.  In fact, I think this is soo 
good it should be added
as a "case study" to the serialization library documentation.

Robert Ramey