Re: Re: Serialization when using virtual inheritance
Thanks Robert. This partially worked... Your comment about putting the BOOST_CLASS_EXPORT macro into the header keyed me into something. I am using the BOOST_CLASS_EXPORT(derived) macro, but I've been placing them into the source (cpp) file instead of the header (h) file. With my system, when I put BOOST_CLASS_EXPORT(derived) into the header file, I get a multiply-defined error at link time (the offending code is boost::archive::detail::guid_initializer<class,...> since the header is included multiple times when I use the class. As a test, I setup a sandbox with a stripped down system and was able to get it to work when I put the BOOST_CLASS_EXPORT in the header, but not when it is in the cpp file. Q: Why does the location of the BOOST_CLASS_EXPORT matter? Is it doing order-depended initialization upon bringing up the system? Q: How do I avoid the mutiple defined error in the linker? Thanks again for your help and the library :) -Eric
MessageEric, Your original post was missing friend class boost::serialization::access; from the class declarations. Is that the case in your actual code? I'm not sure is Robert meant to say that BOOST_CLASS_EXPORT should go in the header. I place these calls in a cpp file with the appropriate archive header inclusions. Jeff Flinn PS. In the future, can you limit postings to text only? It makes it difficult to avoid top posting. Also reply to specific postings in order to preserve message threading, since many of us use the gmane.org news reader to view and respond to messages. "Eric" <eric-public@omnicurious.com> wrote in message news:001601c564d9$35709a60$0a00a8c0@FASTBRICK... Thanks Robert. This partially worked... Your comment about putting the BOOST_CLASS_EXPORT macro into the header keyed me into something. I am using the BOOST_CLASS_EXPORT(derived) macro, but I've been placing them into the source (cpp) file instead of the header (h) file. With my system, when I put BOOST_CLASS_EXPORT(derived) into the header file, I get a multiply-defined error at link time (the offending code is boost::archive::detail::guid_initializer<class,...> since the header is included multiple times when I use the class. As a test, I setup a sandbox with a stripped down system and was able to get it to work when I put the BOOST_CLASS_EXPORT in the header, but not when it is in the cpp file. Q: Why does the location of the BOOST_CLASS_EXPORT matter? Is it doing order-depended initialization upon bringing up the system? Q: How do I avoid the mutiple defined error in the linker? Thanks again for your help and the library :) -Eric ------------------------------------------------------------------------------ _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
MessageActually, the export.hpp has to come after any *archive.hpp due to the "trick" used to instantiate the appropriate code. On some compilers, one can get multiple symbol errors. I think the only way to handle this is to be sure its included at most once or tweak the linker switches to override the error. Robert Ramey "Eric" <eric-public@omnicurious.com> wrote in message news:001601c564d9$35709a60$0a00a8c0@FASTBRICK... Thanks Robert. This partially worked... Your comment about putting the BOOST_CLASS_EXPORT macro into the header keyed me into something. I am using the BOOST_CLASS_EXPORT(derived) macro, but I've been placing them into the source (cpp) file instead of the header (h) file. With my system, when I put BOOST_CLASS_EXPORT(derived) into the header file, I get a multiply-defined error at link time (the offending code is boost::archive::detail::guid_initializer<class,...> since the header is included multiple times when I use the class. As a test, I setup a sandbox with a stripped down system and was able to get it to work when I put the BOOST_CLASS_EXPORT in the header, but not when it is in the cpp file. Q: Why does the location of the BOOST_CLASS_EXPORT matter? Is it doing order-depended initialization upon bringing up the system? Q: How do I avoid the mutiple defined error in the linker? Thanks again for your help and the library :) -Eric ------------------------------------------------------------------------------ _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hi Robert (and Jeff):
Actually, the export.hpp has to come after any *archive.hpp due to the "trick" used to instantiate the appropriate code.
That was the problem! I only used the xml_oarchive object in the main() function, so I only included the respective headers in the main. The rest of the code included the export.hpp header. So, I changed my common include file to also include the *archive.hpp headers and everything is working well. The only thing that I've noticed is that sometimes the objects won't be found when I have 2 or more abstract classes between the base and the final concrete object. The concrete object is registered, but it looks like the (Derived,Base) pair isn't being found. Any advice on where I went wrong on that is appreciated. In the meantime, I'm using void_cast_register<>(...) to register the base class and the top derived class and everything works great so far :) -Eric
On some compilers, one can get multiple symbol errors. I think the only way to handle this is to be sure its included at most once or tweak the linker switches to override the error.
Robert Ramey
"Eric" <eric-public@omnicurious.com> wrote in message news:001601c564d9$35709a60$0a00a8c0@FASTBRICK... Thanks Robert. This partially worked... Your comment about putting the BOOST_CLASS_EXPORT macro into the header keyed me into something.
I am using the BOOST_CLASS_EXPORT(derived) macro, but I've been placing them into the source (cpp) file instead of the header (h) file. With my system, when I put BOOST_CLASS_EXPORT(derived) into the header file, I get a multiply-defined error at link time (the offending code is boost::archive::detail::guid_initializer<class,...> since the header is included multiple times when I use the class.
As a test, I setup a sandbox with a stripped down system and was able to get it to work when I put the BOOST_CLASS_EXPORT in the header, but not when it is in the cpp file.
Q: Why does the location of the BOOST_CLASS_EXPORT matter? Is it doing order-depended initialization upon bringing up the system?
Q: How do I avoid the mutiple defined error in the linker?
Thanks again for your help and the library :)
-Eric
basically you have to a) "register" or "export" any concrete classes serialized. b) serialize the base object from every derived class - including intermedieate ones. c) If you use export - it shoiuld be after the *_archive.hpp files. If its not - it should fail to compile That's all that should be necessary. It has been my intention to permit "export" to be only in the header. I don't think that 1.32 it quite worked out that way but I'm trying to fix this. Robert Ramey Eric wrote:
Hi Robert (and Jeff):
Actually, the export.hpp has to come after any *archive.hpp due to the "trick" used to instantiate the appropriate code.
That was the problem! I only used the xml_oarchive object in the main() function, so I only included the respective headers in the main. The rest of the code included the export.hpp header. So, I changed my common include file to also include the *archive.hpp headers and everything is working well.
The only thing that I've noticed is that sometimes the objects won't be found when I have 2 or more abstract classes between the base and the final concrete object. The concrete object is registered, but it looks like the (Derived,Base) pair isn't being found. Any advice on where I went wrong on that is appreciated. In the meantime, I'm using void_cast_register<>(...) to register the base class and the top derived class and everything works great so far :)
-Eric
On some compilers, one can get multiple symbol errors. I think the only way to handle this is to be sure its included at most once or tweak the linker switches to override the error.
Robert Ramey
"Eric" <eric-public@omnicurious.com> wrote in message news:001601c564d9$35709a60$0a00a8c0@FASTBRICK... Thanks Robert. This partially worked... Your comment about putting the BOOST_CLASS_EXPORT macro into the header keyed me into something.
I am using the BOOST_CLASS_EXPORT(derived) macro, but I've been placing them into the source (cpp) file instead of the header (h) file. With my system, when I put BOOST_CLASS_EXPORT(derived) into the header file, I get a multiply-defined error at link time (the offending code is boost::archive::detail::guid_initializer<class,...> since the header is included multiple times when I use the class.
As a test, I setup a sandbox with a stripped down system and was able to get it to work when I put the BOOST_CLASS_EXPORT in the header, but not when it is in the cpp file.
Q: Why does the location of the BOOST_CLASS_EXPORT matter? Is it doing order-depended initialization upon bringing up the system?
Q: How do I avoid the mutiple defined error in the linker?
Thanks again for your help and the library :)
-Eric
participants (3)
-
Eric -
Jeff Flinn -
Robert Ramey