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
(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 (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-e... Sent from the Boost - Users mailing list archive at Nabble.com.