Guy Prémont wrote:
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.
We've got different problems. You're interested in getting your application to work, while my concern is getting to the root of the problem. If I add your "fix" without really knowing is going on, I end up hiding the problem which will only show up again in a form even harder to discover. In this particular example, I want to know why the singleton is geting created in the main line if there is no serialization code there. When I see this, I can suggest a fix for the user, but more importantly perhaps figure out a way to trap this compile time with a static_error or static_warning. If I can't do that, it will give me another reason to enable the trapping at runtime. (with user option to override).
There is an implicit assumption that serialization code that is in a DLL will only be invoked by code that DLL.
not quite. There is an implicit requirement that serialization code be defined in only one place.
I think it is too limitating,
I agree that it is limitiing. But that's not the same as being a bad idea. It's limiting to inhibit linkage to both static and dynamic runtime libraries but doing so is a bad idea. So trapping and prohibiting this behavior makes one's programs more robust. That is, not everything that might be doable is a good idea to do.
maybe some other symbols need to be exported, beside void T::serialize().
I've looked at this in some detail, and I don't think that there is a simple universal fix which won't break some user programs in a way which is impossible to track down. To summarize, I want to trap this behavior. I realize that this breaks a lot of programs using DLLS. I would argue that they are likely broken anyway (at a minimum they suffer from code bloat). But I also recognise that overriding this trap is the most expedient solution in many cases. Robert Ramey Robert Ramey