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

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-11-08 11:36:44

Topi Mäenpää wrote:
> Debugging continues...

> 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.

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?

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.

>> Could someone point me out a way to work around this? Any temporary
>> solution will do until the problem has been identified and fixed.

see above.

> I have dug deep into the library but have not been able to identify
> the problem. I'm getting a bit frutsrated... Any help will be
> appreciated.

I'll do what I can.

Robert Ramey