Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at