Re: [boost] [serialization] Compatibility between 1.32 and 1.33

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
>>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.