Re: [boost] [serialization]Boost.Serialization1.33.0BreaksSerializationCodeinDLLs

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-09-06 11:25:19

martin.ecker_at_[hidden] wrote:
> Hello,
>
> Robert Ramey wrote:
>> What I'm worried about are the virtual function calls routed through
>> the
>
>> base class vtable.
>
> Can you direct me to where in the Boost.Serialization code this is
> happening? I'd like to have a look at this. What base class are you
> referring to?

look at extended_type_info.hpp

class extended_type_info
...
    virtual bool
    less_than(const extended_type_info &rhs) const = 0;

Look at void_cast.hpp

struct ... void_caster
...
// each derived class must re-implement these;
virtual void const * upcast(void const * t) const = 0;
virtual void const * downcast(void const * t) const = 0;

Look at archive_pointer_iserializer

    virtual const basic_iserializer & get_basic_serializer() const = 0;

and others as well

> Of course you're right. Simply including the headers doesn't trigger
> anything.

I did when we implemented auto-link.  But thanks in large part to Joaquins 
efforts this has been fixed so that things work the way they should.  That 
is - merely including a header from boost/serialization will not trigger 
linkage to any library or DLL.

> but for example using BOOST_CLASS_EXPORT in a DLL and then
> using archives from the main application should trigger the problem
> for type info objects.

Only if a header from boost/archive is being included.

> if I'm not mistaken. Also using archives from
> multiple DLLs, which is not an uncommen scenario for us, will trigger
> multiple instances of static members in header files.

This is the key trigger and source of the problem.  My current thinking is 
that is not addressable from within the library itself.  The best we could 
do is detect when multiple DLLS create duplicates of these static objects 
and throw an exception.  This would be very helpful in creating code that is 
guarenteed to work.

I've described what I don't think I can do and what I can do.  I'm not sure 
what I can offer here, but here's what I can suggest.

There are many ways/styles of organizing code in DLLS and libraries.  Many 
of these will create no problem. Consider this:

Suppose you have  a lot of complicated types in your code.  If each DLL had 
all the code for a type or group of types, there would be no problem.  No 
DLL would contain the same static global object as any other DLL.  If you 
are using polymorphic_archives (as I believe you are) this would create a 
beautiful system of DLLS that don't intersect.  No duplicated code.  And 
your code for a particular type would be all in one place - easing 
maintainence and upgrades.  Note that code in one DLL could easily call code 
in another DLL without creating problems.  Combined with Boost auto-link 
(and just a little pulling of hair) this creates a great system of 
orthogonal DLLS which can be called in any combination from any program. 
This is a system with a lot of the benefits of CORBA or microsoft COM with 
almost none of the grief.   Note that  a future test will explicitly test 
the usage of the serialization library as part of a "plug-in" which is what 
I've described here.  Unfortuntatly, to make this work, extended_type_info 
has to be enhanced slightly by adding in a "class factory" that will create 
an object given its export id. (or something like that - still in the 
conceptual stage).

If you have a smaller number of types but want to generate DLLS - one for 
each type of archive, this can be done by making a small module for each 
archive similar to text_oarchive.hpp.  Then you have one DLL for each 
archive type. This is basically what I did for the common code shared 
accross all archives and it has worked very well.

If the above is not doable or appropriate, I would be curious to know about 
it.   One writes a library with some sort of anticapted usage in mind.  Of 
course, he can't think of everything.  So I'd love to hear about cases where 
the current system can't be made to work.

Robert Ramey