Edward Diener wrote:
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.
Well, that would be my preference, but in some cases its unavoidable. In the serialization library I've got a couple of situations: export.hpp: the function of BOOST_CLASS_EXPORT("classname") is to instantiate code for the particular class for all archives used. The list of all archives used is built from looking at the guard macros from previously seen *archive.hpp files. This permits instantiations to be limited to those *archive classes actually used whose declarations have actually been included. That alternative to this would be to instanciate code for all archives - which would make programs much bigger and take much longer to compile. two-phase lookup: In general, the existence of two-phase lookup can alter the symantics of the program depending on header order. I believe that this can be addressed with partial template specialization but not all compilers supported by the serialization library support this. This resulted in a bunch of quirky and non-obvious rules about which namespace to put serialization specializations in - see the 1.32 documentation. The rules depended on whether or not partial template specialization was supported. So the stl serialzation was filled with alot of #ifdef ... . By adhereing to the rule that all *archive.hpp headers come before all *serialization headers all these problems were resolved. typeinfo_implementation.hpp The serialization system needs a system for handling the type of data at runtime. During the review, there was one reviewer who made a point that RTTI should not be required. I wasn't really convinced but it turned out I had to make a thing called extended_type_info which supplemented the functionality of RTTI by adding GUID (globally unique identifier - a string constant). As I worked on this, I was able to factor out the implementation of this so that in fact I wasn't really tied to RTTI to implement it. The result was that the system permits one to plug-in his own preferred extended_type_info implemention. This is tested and demoed in test_no_rtti. So far so good. Now it turns out that no one really uses this facility as the RTTI one is more convenient. So I implemented the idea that if no type_info system has been #included, #include the extended_type_info_typeid.hpp one as a default. So, that is how things arrived at the current situation. As I said, it wouldn't be my first choice, but I find it much preferable to the alternatives. So I imposed the rule: "all <boost/archive/...> should be listed before all the <boost/serialization/...> includes" Its very easy to remember and is enforced by and #error ... if the rule is violated. It does inhibit the mixing of <boost/archve/..> and <boost/serialization/..> includes other header modules. But in view this should never be done anyway as doing so compromises the orthogonality of the <boost/serialization/..> and <boost/archive/..> headers which is a key concept of the library implementation. I'm sitting here hoping against hope that this will not turn into another very long thread. Robert Ramey