|
Boost Users : |
Subject: Re: [Boost-users] [serialization] Polymorphic serialization withpolymorphic archives problem...
From: Bogdan (bogdan.indy_at_[hidden])
Date: 2010-02-23 13:55:11
I agree, the DLL case seems to be the most useful.
I double-checked and the test that comes closest to this scenario
(test_dll_exported.vcproj) is using template-based definitions of the
serialization functions.
The test project illustrating my question is very similar to
test_dll_exported.vcproj but it doesn't use any template definition. Please
find it attached to this message.
Just let me know if there is any other way I can help.
Thank you,
Bogdan
> > Thank you for your reply. The serialization functions are not inline:
> > their bodies are defined inside the DLL.
> >
> > I did the following experiments:
> >
> > - I skipped manually the registration exception in the debugger and
> > it turns out that all the serialized classes have their serializers
> > registered twice. - if in the main function I do not call
> > serialize/deserialize, the program runs ok; I agree with you, the
> > program doesn't do anything but it proves that the registration is
> > triggered by the actual usage of the serialization functionality and
> > not by any eventual inline.
> >
> > I am under the impression I followed all the directions in the
> > documentation and yet I keep hitting that glitch.
>
> I thought I included demos and tests to implement this very scenario.
> Look through the demos/tests and double check this. If there
> is a demo/test that works and emulates your situation maybe
> we're done. If not, perhaps you might want to modify the
> demo/test so it fails and then send it to me.
>
> Robert Ramey
>
> >
> > Thank you,
> >
> > Bogdan
> >
> > PS.
> > As for the case where boost serialization links as a static inside a
> > user DLL, it fails, indeed, due to the compile stripping out code. Is
> > there a workaround for this you would suggest?
>
> The serialization library uses boost/serialization/force_include.hpp to
> implement this. This might be made to work but is a compiler
> dependent hack. I would prefer we get to the bottom of why
> the DLL situation doesn't work as I would expect.
>
> Robert Ramey
>
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net