Boost logo

Boost :

Subject: [boost] [Serialization] extra_detail namespace breaks ability to multiply export classes
From: Number Cruncher (number.cruncher_at_[hidden])
Date: 2011-02-16 11:53:00


I've been using serialization in a client-server application where the
client and server support different archive types, and the same
"message" classes need to be exported for a different set of archives in
the client and server cases.

For example:
*Client*: links to libNetwork. libNetwork supports export of Message
class by, e.g.

Message.hpp:
struct Message {
};
BOOST_CLASS_EXPORT_KEY(Message)

network.cpp:
   #include <network_oarchive.hpp>
   #include <network_iarchive.hpp>
   #include <Message.hpp>
   BOOST_CLASS_EXPORT_IMPLEMENT(Message)
   template void Message::serialize<network_oarchive>(.......);
   template void Message::serialize<network_iarchive>(.......);

On the server, I also need serialization support for Message over a new
archive type which only the server knows about:

*Server*: links to libNetwork AND libServer. libServer supports export
of Message class by, e.g.

server.cpp:
   #include <server_oarchive.hpp>
   #include <server_iarchive.hpp>
   #include <Message.hpp>
   BOOST_CLASS_EXPORT_IMPLEMENT(Message)
   template void Message::serialize<server_oarchive>(.......);
   template void Message::serialize<server_iarchive>(.......);

For boost 1.43 and earlier, this was all fine; the client had sufficient
serialization code for its archives and so did the server.

With 1.45, boost/export.hpp dropped the anonymous namespace used for
GUID instatiation so now the
boost::archive::detail::extra_detail::init_guid<Message>::g symbol is
multiply defined (first in libNetwork, then in libServer) and I can't link.

If drop the BOOST_CLASS_EXPORT_IMPLEMENT from libServer, I get
unregistered class exceptions on the server, because the
guid_initializer in libNetwork never "knew" about my server_oarchive.

What was wrong with the anonymous namespace usage?
Any help appreciated,
Simon


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk