Martin Slater wrote:
I just ported all our code using Boost.Serialization over to 1.33 today and came across similar problems so I thought I'd add some comments as additional data points. In all cases the problems were trivial to fix (making Save() member functions const for example) and only came across a single case of serialising a local variable in our code, the fix there was also relatively trivial, so all in all this didn't cause us much grief at all.
OK - good to know - one more data point. I wonder if that local variable was being tracked. In this case you fixed a potential error.
The bigger problem I have is with the added included dependancy order (archives must be included before any other serialisation files) which caused a big rearrangment of our headers and was a pain to deal with. Luckily for us these were all internal headers but it just reminds me of the problems with header dependancy that boost\serialisation\shared_ptr.hpp had and that have been happily resolved in this release. This is a much bigger issue for me and something that really should be readdressed.
This is caused by two circumstances: a) for boost/serialization/export.hpp relies on previious inclusion of archive headers to know what archives to instantiate code for. This the same as version 1.32 b) The new requirement to support auto-linking. Auto-linking is forced by including a header whether or not the code is actually needed. The new headers skip those portions which provoke auto-linking if no archive headers are included. This permits headers to include serialization and still be included in other programs which don't use serialization without required link in a library which is not used. I've resolve to make the rule "include archive headers before serialization headers\" conditional on the usage of auto-linking. I'm not sure this is a great thing. It will address the concerns of those who have had an issue with this. But it will also require that a program which is developed on say GCC will have to suppress auto-linking with a compile time define when the program is compiled on a VC or borland. I'm still mulling this over. Robert Ramey