From: Robert Ramey (ramey_at_[hidden])
Date: 2006-05-03 10:47:15
David Abrahams wrote:
> "Robert Ramey" <ramey_at_[hidden]> writes:
>
>> David Abrahams wrote:
>>> "Robert Ramey" <ramey_at_[hidden]> writes:
>>
>>> However, since I happen to be intimately familiar with what's
>>> required here, I'm willing to work up a complete patch for you if
>>> you'll tell me I won't be wasting my time. It would give me the
>>> chance to the "instantiate arbitrary code from a class template
>>> body" abstraction into a separate sub-library.
>>
>> That would be ideal from my point of view - please feel free to
>> check it in.
>
> Great!
>
> I ask only that you update the documentation, to note that archive
> authors should invoke BOOST_SERIALIZATION_DECLARE_ARCHIVE to make
> their archives availabe to this mechanism, and to remove the warning
> about header ordering.
>
> You have two choices about how I'll handle backward compatibility:
>
> 1. Require that all user-written archive headers be updated with the
> next release of this library
>
> 2. Leave enough of the old mechanism in place so that existing code
> will still work as long as it follows the header ordering rule with
> respect to export.hpp
Either of the above would be just fine as far as I'm concerned. Go
for whichever is easiest. From the mail on the user's list I don't think
that many users actually create archives or derivations of existing ones.
And adding a macro to an archive description is very small burden
which occurs once per archive class - almost never. A small price
to pay to eliminate the header order questions that the come up
all the time. It would be nice if we could automatically detect that
such a macro is absent and trap right there - but off hand I don't see
a way to do this. We'll just have to add something to the documentation.
Not a big deal.
> okay, maybe three choices:
>
> 3. Tell me that archive authors outside the library *already* have to
> invoke some macro that I don't know about, and I can add the effect
> of BOOST_SERIALIZATION_DECLARE_ARCHIVE to that macro's
> implementation.
I don't think there is currently any such requirement. I would expect that
most if not all archives derived from basic_oarchive.hpp or whatever. Maybe
that might be useful - but as I said I don't see anyway to make the upgrade
truely idiot-proof.
>
> Please let me know which of those angles I should pursue.
So as I see it its the following
a) replace export.hpp with a newer version.
b) add a macro to each archive class declaration file
c) re-work the test to cover the new header order
d) update documentation to reflect the above. (I can do this)
Robert Ramey