David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> 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.