Re: [boost] [serialization] Compatibility between 1.32 and 1.33
----Original Message---- From: Robert Ramey [mailto:ramey@rrsd.com] Sent: 05 July 2005 18:35 To: boost@lists.boost.org Subject: Re: [boost] [serialization] Compatibility between 1.32 and 1.33
David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
What is the mechanism at work here? Anything involving an #include order dependency worries me, because usually these things are a playground for ODR violations or other inducers of undefined behavior.
The idea is that I didn't want to burden user's of the library with loading the shared_ptr_132.hpp header if they don't need it. So if you don't need to read older archives one can use:
#include <boost/serialization/shared_ptr.hpp>
which is what everyone would expect. This skips over useless and wasteful code that is not needed.
If one needs his code to be able to read shared_ptr archived under the 1.32 system, he would use:
#include <boost/serialization/shared_ptr_132.hpp> #include <boost/serialization/shared_ptr.hpp>
Of course an alternative would be for <boost/serialization/shared_ptr.hpp> to include .../shared_ptr_132.hpp but I thought people without old archives would object to that - as I would personally.
It seems to have been a major design aim of yours to minimize the amount of code dragged into the compiler and into the executable. My impression is that a LOT of the comments on the serialization library have related to the choices you have made in pursuit results of that design. I would like to suggest that you have over done it. Personally, I would expect serialization of old archives to "just work" (and would be very concerned if it didn't). In this particular case, I think shared_ptr.hpp should include shared_ptr_132.hpp /unless/ the user has defined BOOST_SERIALIZE_NO_LOAD_132_SHARED_PTR (or some more elegant name) beforehand. That way the concerned user can save themselves the overhead, whereas the default is safe. In general, I think it would be better if you worried less about including unnecessary code (I'm not saying you shouldn't worry about it, just worry less.) -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434
Martin Bonner wrote:
In this particular case, I think shared_ptr.hpp should include shared_ptr_132.hpp /unless/ the user has defined BOOST_SERIALIZE_NO_LOAD_132_SHARED_PTR (or some more elegant name) beforehand. That way the concerned user can save themselves the overhead, whereas the default is safe.
I agree with this. For those users who start using serialization in 1.33, will they notice? But for those of us who already use 1.32 and have archives with shared_ptrs will suddenly have problems until we get the appropriate includes sorted out. I'd rather backwards compatibility just worked. Cheers Russell
"Russell Hind" <rh_gmane@mac.com> wrote in message news:dag9aq$661$1@sea.gmane.org...
Martin Bonner wrote:
In this particular case, I think shared_ptr.hpp should include shared_ptr_132.hpp /unless/ the user has defined BOOST_SERIALIZE_NO_LOAD_132_SHARED_PTR (or some more elegant name) beforehand. That way the concerned user can save themselves the overhead, whereas the default is safe.
I agree with this. For those users who start using serialization in 1.33, will they notice? But for those of us who already use 1.32 and have archives with shared_ptrs will suddenly have problems until we get the appropriate includes sorted out.
I'd rather backwards compatibility just worked.
I'll add my vote to this approach. Jeff Flinn
participants (3)
-
Jeff Flinn -
Martin Bonner -
Russell Hind