Re: [Boost-users] [Serialization] Linker error on BOOST_CLASS_EXPORTupgrading from 1.44.0

Subject: Re: [Boost-users] [Serialization] Linker error on BOOST_CLASS_EXPORTupgrading from 1.44.0
From: Robert Ramey (ramey_at_[hidden])
Date: 2011-08-01 13:39:24

Enrico Carrara wrote:
> On Fri, Jul 29, 2011 at 6:35 PM, Robert Ramey <ramey_at_[hidden]> wrote:

> I found a workaround, anyway, tweaking some compiler optimizations. I
> also revised all the header files and moved some code outside, then
> isolated all BOOST_CLASS_EXPORT_IMPLEMENTs in one .cpp and moved any
> other serialization code in other two cpp. This seems to have solved
> my problem.
>
>
> Unfortunately, I haven't found a more effective strategy for reducing
> code bloat, so I am ready to accept/try any further advice in this
> regard.

I don't think there is a more effective strategy for "code bloat".  The
problem is the flip side of inline code instantiation.  On one hand you
get faster code - (no call/return - deep optimization) on the other you get 
smaller code.
This one of the main reasons that the serialization library is really
two pieces - a pre-compiled library for all the code which doesn't
depend on user types, and header library which does depend
on user types.  Generally this works pretty well.  But if your
data structures are deeply nested and serialization is used
in multiple places - you're going to get code bloat.  Happily
there is a solution.  As the application programmer you have the
ability to decide which code you want to segregate into one
module and which code you want to re-instantiate on demand.
Downside is that you have to actively think about this - that's
why we get paid the big bucks.

Another issue crops up with libraries and especially DLLS. It's
possible for instantiations to occur in differing modules.  This
might show up as multiple symbols in linking a static library and
violations of ODR in DLLS.  This latter can create problems
with the serialization library which needs to keep a list of exported
types.  If the type is exported in more than one module, confusion
can occur.  I had a trap in the code to detect this latter - but it
turns out to be too onerous a requirement that users avoid
violating the One Definition Rule - so I had to disable the trip -
for now.  This turns out to be a surprisingly big subject which
the C++ standard has yet to address  - (I believe it's on the menu
though).

Robert Ramey