Robert Ramey wrote:
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: snipped...
Thanks for the explanation. Although I really dislike header file dependencies, the rule that you have about including archive headers before serialization headers is easy to understand. Regarding the partial specialization and no-RTTI problems, and without knowing your internal code, I would just like to suggest that for those using conforming compilers and RTTI you should strive not to impose the header file ordering rule of having the header archives files included before the header serialization files. I realize you are doing this, even in this case, anyway because the BOOST_CLASS_EXPORT("class") works properly with the rule, but I would still seek to eliminate this header file dependency for conforming compilers and those who naturally use RTTI. Do not think, by saying the above, I do not applaud your heroic efforts to get serialization to work with non-conforming compilers and those people who prefer to turn off RTTI, but only that there must come a point where those who use standard C++ should not face any of the restrictions of those who do not. Not that it is necessarily the programmer's fault that their compiler is deficient, or that they must not use RTTI for some reason, but I consider both non-standard C++. As a long shot, and again not knowing the internals, is it not possible to have BOOST_CLASS_EXPORT("class") work as each archive is included, perhaps by including export.h at the end of each of your own archives and building the exported information one at a time ? No I am not trying to create extra work for you <g>, but just suggesting future possibilities to eliminate the very reasonable header file rule you have.