Re: [Boost-users] [Boost Serialization] Problem serializing derived class declared in DLL

Subject: Re: [Boost-users] [Boost Serialization] Problem serializing derived class declared in DLL
From: kmdarkmaster (kmdarkmaster_at_[hidden])
Date: 2011-04-06 02:28:47

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-derived-class-declared-in-DLL-tp3428913p3429993.html
Sent from the Boost - Users mailing list archive at Nabble.com.