Reusser, Edward wrote:
Robert,
Thanks for the quick response. I have ensured that the serialization for each type is located in exactly one place. The header files where the serialization code resides for the derived classes are not global, that is, our build system is set up to ensure that no other library or DLL can reference them.
That is not the issue - the problem is provoked by using serialization from within a DLL.
I believe that I can make the serialization completely independent and contained inside the DLL without much difficulty. However, unless I statically link the serialization library, I don't think I can prevent the macro:
BOOST_CLASS_EXPORT_GUID( class, "ClassNameText" )
from initializing the global table inside the serialization DLL (which is dynamically linked).
Its not necesary - or possible - to prevent it. The library can live with it - atlease versions 1.34 and later.
I noticed that when I tried to use the other registration technique you describe, register_type<T>(), this also calls the registration code in the serialization DLL on load, so that doesn't solve the problem.
correct.
It doesn't seem very practical to serializing in/out a prototype of each derived class into the archive initially because it would increase the archive size by a lot.
should not be necessary.
Too bad there isn't a mechanism for creating a registration table specific to the DLL where the classes are serialized. If the global table was of the following structure:
using namespace std; map< HMODULE, map<string, ETI*> >;
Then the above macro would simply use AfxGetInstanceHandle (in the case of windows, I am unsure what the corresponding calls in other OS's would be), to pass the HMODULE handle.
As I've said, it turns out the dynamic manipulation of the table works OK. (At least 1.34 + - I don't remember exactly when I fixed it but I think it was in last year.) So I believe this problem is slolved - though you might not have the solution yet. Robert Ramey P.S. Actually its been so long since 1.34 was frozen for release - I don't even know if 1.34 includes the fix. I do remember that I fixed it - I just don't remember when. RR