From: Edward Diener (eddielee_at_[hidden])
Date: 2005-07-05 16:22:59
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
>>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
>>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
>>Regarding the particular situation explained above, I would much
>>that the end-user have to #define a macro for a particular file in
>>to load a previously archived object from an earlier version, if that
>>what it takes, than that he/she need to include header files in a
>>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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk