Hi everyone, Thanks for the reply, The exception I got was a boost::archive::archive_exception, please note that I never get this exception if the derived class + export macro is in the same executable as the base class + main. Francois Mauger wrote:
i think you should read: it works perfectly if *BOOST_CLASS_EXPORT_GUID* is in the main execution. you can still put your derived class wherever you want !
You may be right but if the derived class is in the DLL there is just no way to call the macro EXPORT in the executable (you need the definition of the exported class for the macro to work), so it turns out to be the same. Francois Mauger wrote:
It looks like an issue I've met a few weeks ago. After investigation (note may be I'm wrong but I can only report of my understanding which is far to be good !) I now believe it is NOT possible to scatter such serialization export bits in different places (DLL vs executable, DLL vs DLL). It is because, as far as I understand the concept, the "export" mechanism you mentioned is implemented in the DLL object scope (probably using some static 'local' dictionary instantiated in the DLL scope or the executable scope, depending of the user). You can imagine such case: your base class is registered in the DLL but your Daughter class is registered at the level of the executable object scope : thus there is no way to make them communicate about their relationship. Both dictionaries (one per instantiation unit) acts in different words and know only one subset of the serializable classes to be used in your executable.
Thanks for the explanation, I still have one question through : if I mark a class as exported with the __declspec(dllexport) in the DLL, the class is "exported" to the outside world, so we have parent class and child class registered in the same object scope right ? And how about DLL that is loaded implicitely ? In this case the definition of its class is knowned by the executable from the beginning, will it help solving this issue ? Francois Mauger wrote:
In your case, I think you could step back to the previous approach where all serialization stuff is instantiated in the executable. The alternative is to probably to move your xml_archive ser/deser code in some resource implemented in the DLL and promote some reader and writer classes for XML archives as an element of your DLL, the later being the unique place to safely embed the problematic bits. I'm afraid there is not intermediate.
Well my boss want this feature and I have no power over the decision made. I myself don't think using those numerous DLLs is a good idea either. Once again, thank you for your anwser, if anyone knows a way to get around this issue, please continue the discussion. -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Serialization-Problem-serializing-d... Sent from the Boost - Users mailing list archive at Nabble.com.