Robert Ramey
writes: And you still have the crash? - maybe I'm wrong about the cause. Or maybe my advice doesn't go far enough.
using something like
ar << x // where x is an type mytype *
in the mainline while the dll contains similar code might also create problems. I'd have to think about this some more?
Robert Ramey
Yes, I still have the crash.
I have a very small sample solution that causes the crash. I have only one Dll containing one interface (INode) and one concrete class (Node). The Node contains a list of INode*. If I call the serialization of one Node (as an object) from the main program, it crashes.
(1)--- Node table; ... outputArchive << (const Node&)table; Node table2; ... inputArchive >> table2; // crashes ---
If the main program contains the serialization of a Node* too, it works.
(2)--- Node* pTable = ...; ... outputArchive << pTable ; Node* pTable2; ... inputArchive >> pTable2; // the code (1) works without a crash now ---
It is exactly the setup I have and it also produces the crash. The way I understand what is happening, it is the invocation of serialization in the main program that causes singleton to be instantiated in the main executable, in addition to those in the DLL. Even though the actual serialization code is only the DLL. The fix I did in basic_iarchive::register_type, posted previously, prevents the overriding of an existing pointer_iserializer by a NULL. It is somewhat hacky as it does not address the cause of the problem, but it is an effective fix. There is an implicit assumption that serialization code that is in a DLL will only be invoked by code that DLL. I think it is too limitating, maybe some other symbols need to be exported, beside void T::serialize(). Guy