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

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-07-06 11:00:55

Vladimir Prus wrote:
 Robert Ramey wrote:
>
>>> 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.
>
> I recall that I did suggested one approach. BOOST_CLASS_EXPORT can
> register the class with all previously included archives and,
> unconditionally, with polymorphic archive. During saving, you can
> check if the saved class is registered with specific archive type.
> If not, you wrap archive in polymorphic archive and save. That would
> be slower, but in most situation extra virtual function call won't
> be a practical problem.

> In the rare case where it will be a problem, user can:
> 1. Include necessary archive headers
> 2. Invoke BOOST_CLASS_EXPORT *again* in his module, after including
> another archive header. If BOOST_CLASS_EXPORT tolerates multiple
> invocations, this will instantiate the code for the needed archive
> type, and make saving to that archive type go without polymorphic
> arhive.

export.hpp is already quite complicated.  This would seem to add a huge
amount of effort at compiler and at rntime.  It would also add dead code to
almos t every executable using the library.  It would seem a huge price to
pay just to permit one to say.

#include <boost/serialization/export.hpp
#include <boost/archive/text_iarchive.hpp>

rather than

#include <boost/archive/text_iarchive.hpp>
#include <boost/serialization/export.hpp

> I never understood this. BTW, did you have a chance to try my ADL
> patch?

I considered your patch, tested it on my own system, and rolled into the
main CVS sometime ago.

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

> Sorry, it might turn into a long thread after all, because you
>haven't still answered the attached message of mine. To summarize, I
>claim that the rule immediately prevents the "include my own headers
>right at the top" practice that I use.

Here is a copy of your preveious post - I'll answer it here

>>
>>>> How? Clearly, if I include base_object.hpp in a header, I cannot
>>>> obey the above rule. Ok leaving just:
>>>>
>>>>    #include <boost/serialization/access.hpp>
>>>>    #include <boost/serialization/split_member.hpp>
>>>>    #include <boost/serialization/base_object.hpp>

>> I don't understand you. If A.hpp contains the above, and my .cpp files
>> contains
>>
>>   #include "A.hpp"
>>
>>   #include <boost/archive/text_oarchive.hpp>

I would recommend taht the above be changed to:

#include <boost/archive/text_oarchive.hpp>
#include "A.hpp"

>>
>> Please take a look at:
>>
>>   http://zigzag.lvk.cs.msu.su/~ghost/serialization_problems/
>

I looked at your examples, made some changes in the library, tested them an
checked them in.

>> The second example is typical and very easily resolved. Just move  the
>> *archive includes above static.h (which indirectly include the
>> serializations of for a class Module data.

>As I did explain, I want "static_data.h" (just like every header
>corresponding to my .cpp) to be the very first include in my .cpp file.

>Did you see my arguments? Do you find them weak? If so, can you explain
>why?

Your requirement that static_data.h be first in every header conflicts with
my requirement that serialization headers be after archive headers. I've
explained why, given the alternatives I have available, I think its the best
one.  That's the best I can do.

Robert Ramey