Re: [Boost-users] [Serialization] 1.56.0 - unregistered_class exception while using EXPORTs

Subject: Re: [Boost-users] [Serialization] 1.56.0 - unregistered_class exception while using EXPORTs
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-08-20 11:56:57

aragonsr wrote
> It's on load.
> 
> I'm just testing with a single derived class.
> 
> My base class is an abstract polymorphic base class. So I didn't use
> "base_object
> <BaseType *>
> (this)" in the derived class. Is this correct? There's nothing in the base
> class to serialize. it sounds like you're telling me, even if it's
> abstract, I should go ahead and use "base_object
> <BaseType *>
> (this)"? I'll give that a shot.. I guess..

Basically, the void_cast ... has to be there.  base_object includes it.  If
you don't user base_object, you have to use void_cast.  That is you can
either include null serialization in the base or use void_cast... Either
should work just as well.

> "But most linkers strip out code which is known to be called."
> That doesn't make sense. Do you mean "which is NOT called"?

struct A {..}; // abstract base class
struct B : public A {...};

iarchive >> a;  // makes no reference to type B.

Sooo the compiler will say - hmmm - no one is referencing B::save and
B::load so we might as well just eliminate this "dead" code.  That's what it
does.  Problem isn't discovered until the program is run and the downcast
can't be found.  It's even worse.  Some compilers only do the "dead code
stripping" when running in release mode.  So your program works with
debugging but fails on release.  No fun unless you can ask on this list. 
But wait! it's even worse!  When building DLL dead code stripping may well
not occur since the compiler knows that there will be a lot of unreferenced
functions and can't know that it should strip dead code.  So things might
work when using as a DLL but not when using a static library.  The compiler
say - oh, no need to include functions where no one calls them (that I can
see).

> I didn't know about the dll static lib thing. Never thought about it. This
> gives me something to chew on for a while. Thanks!

Of course this complicates things as well.

The source of this problem is that all the issues associated with static and
runtime linking are totally undefined by the C++ standard and are in fact
considered as issues totally outside the language itself.
But we also want optimized code.  These propositions conflict.  Perhaps
someday this might be addressed
by including the concept of "modules" in the language.  But it's not clear
if that will ever happen or
if it does happen if it will be useful to actual programers such as
ourselves.

The concept of C++ plugins implemented with runtime linking is very, very
useful on a large project
which needs to be updated after deployment.  However, one can't "just do
it".  One has to spend
real effort doing this.  I have a few suggestions:

a) use dynamic linking for both mainline and all dlls. This helps with the
"dead code stripping" problem
and the one definition problem.  In these case a C library function will
only appear in the C library DLL
and no where else so you won't accidentally have multiple "equivalent"
versions of the same function
in your final program.  First they're not always equivalent.  Second it
saves space to not duplicate. 
Third, a view functions such as stringtok keep an internal state variable -
they are not idempotent.
When multiple versions are included, there will be multiple instances of
these internal variables
with can create a problem which is incredibly difficult to find.

b) Don't use inlined functions in derived classes.  Put all code in the
separate *.cpp files.  This avoids
violations of one definition rule.

c) Be prepared to really think about where the code is that one is going to
call.  You just have to spend time
planning this out.

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/Serialization-1-56-0-unregistered-class-exception-while-using-EXPORTs-tp4666610p4666655.html
Sent from the Boost - Users mailing list archive at Nabble.com.