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

From: Edward Diener (eddielee_at_[hidden])
Date: 2005-07-05 12:06:18

David Abrahams wrote:
> "Robert Ramey" <ramey_at_[hidden]> writes:
> 
> 
>>Klaus Nowikow wrote:
>>
>>>Will a file created with a binary archive from Boost 1.32
>>>be readable with Boost 1.33?
>>
>>That is the intention.
>>
>>
>>>I am just building the latest version from the cvs to try it
>>>myself, but I thought it would also be a good idea to ask this here.
>>
>>I certainly would appreciate someone trying this.
>>
>>Note that for shared_ptr, one will have to include shared_ptr_132.hpp before
>>shared_ptr.hpp in order to be able to load previously archived
>>shared_ptrs.
> 
> 
> 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.

I made a similar point about #include order dependency and the 
serialization library in this NG, but my point was that the creator of a 
library can always make sure that a particular header file is included 
if necessary, through checking #defines, and that the end user should 
never have to worry about header include order.

I think this is really important from an end-user's point of view. I do 
not believe that any library in which, from the end-user's perspective, 
header files have to be included in a particular order can be really 
robust, even though I know that this is sometimes done in some famous 
situations.

Regarding the particular situation explained above, I would much rather 
that the end-user have to #define a macro for a particular file in order 
to load a previously archived object from an earlier version, if that is 
what it takes, than that he/she need to include header files in a 
particular order.

Header file order dependencies, from an end-user's perspective, are a 
minefield it is best to avoid at all costs.