Re: [Boost-users] [serialization] Multiply definedsymbol:guid_initializer

Subject: Re: [Boost-users] [serialization] Multiply definedsymbol:guid_initializer
From: Robert Dailey (rcdailey_at_[hidden])
Date: 2009-04-03 13:48:18

On Fri, Apr 3, 2009 at 1:37 PM, Robert Ramey <ramey_at_[hidden]> wrote:

>  Two things are getting mixed up here.
>
> a) The first is not using RTTI.  You've used the test as an example and
> this seems fine to me.
>

This is the exact behavior I'm looking for. The platform in question does
not support RTTI and thus I cannot use it.

> b) You want to serialize a polymorphic derived class through a pointer to
> it's base class.  This
> is OK too, but requires special care.  The problem is that  C++
> compile/link will generally not
> include code which is not specifically referred to.  This occurs when
> compiling (optimizing out
> dead code) and linking - skipping modules not referred to.
>
> To deal with the second, you have "trick" the compiler/linker to not
> discard your code.  There
> are a couple of ways to do this.
>
> a) Somewhere in the main module, refer to the derived type in the library.
> An easy way to
> do this is to just create one more function in your code which refers to
> the code in the library.
> Well, its not that easy because the C++ optimiser will usually throw away
> the whole call
> if the result isn't used. You can use the "force_include.hpp" to keep this
> from happening.
>

Could you give me a code example for this? I'm not sure what the code for
this is. Do I just define a global function in force_include.hpp and
implement that function in each base class's CPP file? What would the
definition of such a global function have? I obviously have to call this
global function somewhere, where would I call it?

b) You can re-package your library as a DLL.  DLLS are different in that the
> whole DLL
> is imported when the application starts up - not just the functions
> actually referred to.
> The "registers" all the "EXPORT"ed functions and things would as
> advertised.
>
> Sorry it has to be this way.  The whole idea of using a library is to
> automatically
> include only that code which the linker detects is actually called.
> Loading through
> a base class pointer explicitly hides this fact so one has to make special
> effort
> of some sort.  The only other alternative would be to have the linker
> import ALL the
> code in the library which would defeat the reason for having a library in
> the first place.
>

Could you explain to me why having all of the code in the LIB file defeats
the purpose for having a library in the first place?

Of the two solutions you listed above (DLL vs global function), which would
you suggest? Using a DLL seems like the most transparent solution and I
might go for that.

Thanks for your help, I really appreciate it.