...

...

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 ;)