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

Enrico Carrara wrote:

On Fri, Jul 29, 2011 at 6:35 PM, Robert Ramey 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