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:54:35

Also, I'm a bit confused about something else Robert.
All along we've been saying that if the code in the translation unit is not
used, it may be stripped by the linker. What code exactly is being stripped?
I mean, I create my classes before I serialize them and I'm calling member
functions on these instances. So for sure the translation unit is being
"entered" before serialization even begins. Does this not meet the
requirements?

Is the problem that the code generated by BOOST_CLASS_EXPORT() and
BOOST_CLASS_TYPE_INFO() is not being used, and thus stripped?

On Fri, Apr 3, 2009 at 12:48 PM, Robert Dailey <rcdailey_at_[hidden]> wrote:

> 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.
>