Boost logo

Boost :

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

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

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