Re: [boost] [serialization] Compatibility between 1.32 and 1.33

From: Martin Bonner (martin.bonner_at_[hidden])
Date: 2005-07-06 03:35:30

----Original Message----
From: Robert Ramey [mailto:ramey_at_[hidden]]
Sent: 05 July 2005 18:35
To: boost_at_[hidden]
Subject: Re: [boost] [serialization] Compatibility between 1.32 and 1.33

> David Abrahams wrote:
>> "Robert Ramey" <ramey_at_[hidden]> 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_at_[hidden]
Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ,
ENGLAND Tel: [phone]