Re: [Boost-users] [Boost][serialization] Serialization and DLLs

From: Topi Mäenpää (topi.maenpaa_at_[hidden])
Date: 2005-11-08 14:11:40

>>> Could this be related to the fact that the low-level type_info pointer
>>> for the classes is different in the dll and the exe?
>  
> That sounds like it could explain this.
> 
> 
>>> (This is also the
>>> reason why dynamic_cast doesn't work across dynamic library
>>> boundaries.)
> 
> I've never heard of this before.  If this is true it would be key indicator 
> that
> something's wrong.  Is this a known MSVC bug?  That would be very
> interesting to know.

I'm not a pro on this matter, but at least gcc (and its Windows version, 
mingw) have similar "feature". I still need to double-check if I have 
forgotten to include rtti support somewhere, but I have seen a couple of 
different my::dynamic_cast implementations that try to work around this. 
The most well known one might be Qt:s qobject_cast. As far as I know, 
compilers use pointer equivalence to compare type_infos. It seems that 
the type_info pointer isn't exported from dynamically loaded modules, 
which makes dynamic type casting (and also certain exceptions) 
impossible across dll boundaries. I don't know the reason, but I have 
verified this with three different compilers, on Linux and Windows.

> Is it possible to use the non-rtti versions with MSVC
> 
>>> 7.1?
> 
> 
> I have implemented non-rtti version which is documented and tested - 
> test_non_rtti.
> The test verifies that types which are identified with different runtime 
> typing systems
> can inter-operate.  The library includes extended_type_info_no_rtti.cpp (a 
> mis-nomer
> I see now).  This runtime typing system uses the BOOST_CLASS_EXPORT key
> as the type identifier.  So to use this you'll have to fix the 
> "type_info_implementation"
> trait for this type and besure its exported.  This hasn't really been used 
> except in the
> testing (as far as I know).  As far as using it a derived class defined in a 
> DLL where
> the base class is in some other library?

Too bad I found the reason this late. You already had the feature there!

> I reviewed the relevant code and have verified that the serialization system 
> presumes
> that type_info returns the same value regardless of whether the type is 
> implemented
> within a an executable, standard library or dll.  I can't imagine why it 
> would be any
> other way.  I also don't have any other reports of this.  Of course, this is 
> not
> a common usage so that probably doesn't mean much.  Double check that that
> there aren't any differences in things like _cdecl  etc.  Maybe that might 
> explain
> why the run-time type signatures vary depending up where the type is 
> implemented.
> 
> I've started written my own test of this situation but its kind of hung up 
> in some
> in trying to get it worked into bjam. So I haven't finished it.
> 
> I'll do what I can.

Thanks for a thorough inspection of the matter. I finally managed to 
work out a temporary hack that does the thing. Here is how:

Change tkmap/ktmap multisets to sets.
Modify extended_type_info so that it always compares keys literally.
Re-export base classes from wherever subclasses are exported. This 
ensures that the correct key is recorded to extended_type_info even 
though there are multiple distinct instances. The downside is that one 
now always needs a key, but I'm assuming it is the only possible way of 
dealing with shared libs anyway.

Phew! I like the design of the library and the ease of use a lot. Good 
luck this is (at least partially) resolved now, because it would have 
been a show stopper to me. I hope my findings have some use in 
developing an even better version of it :)

Best regards,
Topi (not so frustrated any more, I'm gonna meet the deadline ;)