John C wrote:
Yeah, sorry, I suppose that sounds worse than what I intended. I guess what I really mean is don't assume updates are backwards compatible...
Hmmm - they are meant to be. Sometimes an error is made but it's not THAT often. One thing that does occur is the following: a) things are going along just fine. b) A user posts a problem to the list. This turns out to be some some combination of DLLS, use of export, multiple instantications, virtual base classes, sharead pointer, collection serialization all nested with the user types. c) Something is wrong, but it's not easy to figure out. 1) Turns out to be a library bug. Does happen sorry. But the fix ends up breaking someone's usage. Hopefully, this just results in a compile time error which is easily fixed and we're done. 2) More often, it turns out to be an error on the part of the user about what the library can do or be expected to do. At this point I have two choices. i) resign my self to answering the same question forever. ii) ignore he user's problem, in which case he goes around reporting that "the serialization library is buggy" which of course annoys the hell out of me. iii) Enhance the code to trap the user error at compiler or maybe runtime. An explicit crash ASAP is better than a buried/hidden problem? Unfortunately, this will often trap errors in older code which are now report as new "bugs". What they really were were buried traps that no one has knowingly stepped in yet. This is not meant to be a rant. I'm just trying to make the library such that it's easy to use and hard to mis-use. I don't know how successful this effort has been, that is how many people have tried the library and found to frustrating to use, but there it is. Robert Ramey
Robert Ramey wrote:
John C wrote:
I think this was the main cause of my problem, and this alone might make it work in boost 1.40.0. Since the header file that uses this is in a shared object file that in some cases cannot have any boost dependencies, I had a forward declaration for base_object. I had to remove the forward declaration and #def in the inclusion of the boost export.hpp header for the BOOST_SERIALIZATION_BASE_OBJECT_NVP macro.
It's hard for me to guess what's going to happen if you start messing with the header - especiallly if you only reveal this after the fact.
In order to limit dependencies, I would suggest a different technique. Don't use inline definiition. Use the following in your class declaration:
template<class Archive> void serialization(Archive & ar, const unsigned int version);
In a *.cpp file define the template and explicitly instantiate it for the archive types that you use. This will permit you to confine the inclusion of serialization library headers to a smaller set of files.
When using serialization code (or any template code) with DLLS this technique will also address another problem which is starting to come up - Multiple (and potentially conflicting) template instantiations. This could lead to hellish debug scenarios as well as code bloat. In some cases the library can now detect this problem, but I had to suppress the trap because it broke too much user code. (That is, it detected too many problems in user code.) When I have nothing else to do, I plan to revisit this and provide a trap that the user will be able to explicitly override. It might not help, but at least the user won't be able to say he wasn't warned.
The moral of the story: If you are upgrading boost versions, don't assume the serialization library hasn't changed drastically, especially if you are serializing polymorphic types and even if it works fine in Windows.
Well, the changes didn't seem drastic to me. I think that is an overly harsh and missleading characterisation.
Thanks for the help Robert....
Your welcome.
Robert Ramey
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users