Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at