[boost] Re: [serialization] BOOST_CLASS_EXPORT regression?

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-03-14 14:15:50

Vladimir Prus wrote:
> Robert Ramey wrote:
>
>> Are you sure this worked before?  That would surprise me.
>
> Absolutely. This worked for about half an year ;-)

Well, I can't explain it - oh well

> Yes, I see -- with the current implementation. Maybe, you changed the
> implementation recently?

I'm sure I have - but I can' t imagine how something like this would happen.
I'll look in to it.

>> My suggestion would be to include the archive headers only in the
>> modules that actually invoke serialization. And that be only in one
>> module.  My intention was that each class header contain
>> BOOST_CLASS_EXPORT for its classes and the the "main" or other
>> module (see demo_pimpl) that actually invoked the serialiation would
>> include the headers for the archive classes that are desired.  This
>> makes it easy to switch between archive types for things like
>> debugging, etc.
>
> This is fragile. If I have two modules, linked in one application,
> which
> both use serialization, then if they both include a single header with
> BOOST_CLASS_EXPORT, I'll get link error, right? I don't think it's
> realistic to expect that either:
> 1. Classes are serialized only in one module.
> 2. No header file is used by more that one module.

Not quite.  Header containing the serialization can be specified all over
the place as many times as one wants.

Its the combination if archve and serializaition which would appear in only
one module.  The pimpl example sort of illustrates how I would imagine would
be a practical way of doing this:

a) include BOOST_CLASS_EXPORT(C) in c.hpp
b) make a module c.cpp which implements serialization for all the archives
you plan to use
c) build the c.cpp with granularity to the function level (the requires /Gy
on microsoft platforms)
d) compile c.cpp to the library.
e) your "main" application can import the header c.hpp
f) you link step will include the code corresponding to the combinations of
archive/serialable classes that you actually have used.

Once things are organized in this way you can add/delete code and headers
from your "main" app as you wish and everything is taken care of
automatically

It gets better.

If you follow the above scenario you can compile the serialization
implemention modules to DLLS so that the code only gets loaded when used at
runtime.

It gets even better.

If you follow the above and compile your serializaition modules as DLLS and
use the polymorphic archive. You'll be able to update your main application
and even use archive classes yet to be implemented.

Even better yet.

If the "main" code serializes a pointer to a base class, and a new derived
class is built as a DLL, this new class can be dynamically loaded even by an
older program - plugin capability.

All these thiings are contemplated in the code for the current library. The
last (plugins) hasn't yet been tested. And doing so will likely generate
some changes / bug fixes in the library.  But it has been done by Martin
Ecker in his own customized version of this library.  I've basically
incorporated his suggestions in accordance with boost requirements.

> In my case, I've moved BOOST_CLASS_EXPORT to an implementation file
> and it worked. I am not sure this solution is generally applicable --
> one might
> want header-only class hierarchy...

I know people have had some problems with this in the past.  I believe I've
got this under control - but I don't know for sure.

Note that the instantiation model for C++ has variations across
implementations.  In building the static and DLL versions of the library I
found the simplest and most reliable way to deal with the variety of
platforms was to explicitly instantiate the code I wanted.  This turned out
not to be a problem as I had expected.  I just instantiate all combinations
and include them in the library and let the linker select what it want's to
use.  Crude perhaps, but very effective.  It also has the very convenient
aspect that it greatly lowers build times and forces a more robust code
factoring.

Also I forgot to mention,  there is always the posibiity of setting the
linker switches so taht duplicate symbols are not flaged as errors.  I
believe that this can work, but its too big a hammer for my taste.

Robert Ramey