Christoph Duelli wrote:
Robert Ramey wrote:
Christoph Duelli wrote:
I also get lots of boost::archive::detail::<unnamed>::init_guid<XXXX>::g' defined but not used where XXXX is some class name of mine
Is it possible that the class is marked "EXPORT" when this is not in fact necessary? Well, when *is* it necessary? The serialization code for classes are usually looks like this:
BOOST_CLASS_EXPORT_GUID(Node, "Node")
void Node::serialize(InArchive & ar, const unsigned int /* file_version */){ ar & BOOST_SERIALIZATION_NVP(m_sFileName) & ... ; } void Node::serialize(OutArchive & ar, const unsigned int /* file_version */ { ar & BOOST_SERIALIZATION_NVP(m_sFileName) & ... ; }
Maybe I have misunderstood when I need to used BOOST_CLASS_EXPORT_GUID; I will read up on that again.
ii) maybe a 'bug' (code does no longer compile) Code that used to compile with Boost 1.40 does no longer compile with the 1.41 beta: (I had no time to investigate yet; in case it is obvious for you once you see the code I have decided to include this point in this posting):
boost/archive/shared_ptr_helper.hpp:114: error: cannot convert 'const boost::serialization::extended_type_info_typeid<MEPfad>' to 'const boost::serialization::extended_type_info*' in return (where MEPfad is a class of mine)
In this case the code actually looks wrong to me. I'm curious why it never failed any tests. If you have a small bit of source which traps this problem, I would be curious to see it. I have created a stripped down example that exhibits the error. (Basic ingredients: shared_ptr, binary_iarchive.) See attachment.
The "serialize" function should never be called directly by the app. I'll look into why this is not trapped. Robert Ramey