From: David Abrahams (dave_at_[hidden])
Date: 2006-05-03 11:27:47
"Robert Ramey" <ramey_at_[hidden]> writes:
>> 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.
1 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
I could probably do that at archive construction time, but I'd rather
not add that layer of complication.
> - 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
> 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.
Well option 2 is pretty good in that department.
>> 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)
Although I don't mind doing c), I would appreciate it if you'd rework
the test yourself, before I start. This isn't out of laziness, but
out of a desire to be sure I know I've met your requirements and
expectations. If I rework the test, I could implement something that
you'll find unacceptable. You could put the new test on a branch to
avoid breaking the regressions.
Thanks for your cooperation.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk