Boost logo

Boost Users :

Subject: Re: [Boost-users] [serialization] Polymorphic serialization with polymorphic archives problem...
From: Bogdan (bogdan.indy_at_[hidden])
Date: 2010-02-22 21:05:52


> Hi,
> I have the same scenario, and it's not a problem.
> If i understand (my english is poor, sorry) well.
> But there is differences:
> - I use GCC compilers (but boost is portable).
> - I use static linking.
> Probably this differences should not have consequences on the result.
> I didn't read your code... Had you follow this rules ?
> - Register child class (a simple way is using the
> BOOST_CLASS_EXPORT macro).
> - In the serialize method of your child class, call the
> serialization of parent's class (optional). I use
> BOOST_SERIALIZATION_BASE_OBJECT's macro.
>
> If you register child class it should be ok...
> Regards,
> Damien.
>
>

Hi Damien,

My reply has not been posted in gmane so I try again:

Thank you for your quick reply. I believe I followed the rules:

1. polymorphic_derived1 and polymorphic_derived2 do include the
serialization of the base class via

"ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(polymorphic_base); "

2. there is no usage of BOOST_CLASS_EXPORT ( and there shouldn't be any:
according to the documentation, in a dll setup one must declare
BOOST_CLASS_EXPORT_KEY in the headers containing the classes to be
serialized and BOOST_CLASS_EXPORT_IMPLEMENT in the .cpp files). In my
example, there are exactly three declarations of BOOST_CLASS_EXPORT_KEY: one
in polymorphic_base.hpp, and two in polymorphic_derived2.hpp one for
polymorphic_derived1 and another for polymorphic_derived2. Similarly, there
are only three usages of BOOST_CLASS_EXPORT_IMPLEMENT.

3. for deeper hierarchies where every class can be potentially serialized,
one should probably register all the classes and not just the most derived
children.

I have the feeling that the type of deployment (dll vs exe) is the crux of
the problem. For that, I created four different scenarios with the same
source files and I got the following results:

1. all files in one exe with the serialization library linked statically -
WORKS AS EXPECTED.
2. all files in one exe with the serialization library linked as a dll -
WORKS AS EXPECTED.
3. serialization files in a separate dll. Both the main executable and my
dll link with the dll version of the serialization library:

    main.exe
        my_serialization.dll
        boost_serialization.dll

    my_serialization.dll
        boost_serialization.dll

Builds OK but FAILS at runtime , at run time I get a C++ exception BEFORE
main() in basic_serializer_map.cpp around the line 48:

'archive_exception::multiple_code_instantiation with the message "code
instantiated in more than one module - polymorphic_base"'

4. serialization files in a separate dll. Both the main executable and my
dll link with the static version of the serialization library:

    main.exe
        my_serialization.dll
        boost_serialization.lib
 
    my_serialization.dll
        boost_serialization.lib

Builds OK but FAILS at runtime while trying to serialize with the following
exception thrown in oserializer.hpp(line 424):struct polymorphic::save():

'unregistered void cast class polymorphic_derived1<-polymorphic_base in
function 'int __cdecl main(int,char *[])''

The source code in the scenarios above is identical with the exception of
dllexport/dllimport declaration needed for dlls. Whenever the serialization
code is relegated to a different library it seems there are problems with
boost serialization:
- if boost is linked as a static lib into a user dll, the class serializers
do not get registered at all with their associated map singleton.
- if boost is linked as a dynamic lib into a user dll, the class serializers
register twice with the map singleton of the polymorphic base archive.

I don't want to add them here but I can provide any of the projects above to
those interested.

Thank you all,

Bogdan


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