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.