Re: [boost] Header ordering [was: Vector of Polymorphic Pointers]

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
>>   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
www.boost-consulting.com