martin.ecker@tab.at 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