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@gmail.com> wrote:
On Fri, Apr 3, 2009 at 1:37 PM, Robert Ramey <ramey@rrsd.com> 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.