Re: [Boost-users] [Serialization] unexpected assertregisteringclasses

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-11-13 15:57:37

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