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

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-05-03 11:54:34

David Abrahams wrote:
> "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.

> Well option 2 is pretty good in that department.

I don't think its worth any extra effort to avoid breaking existent
archives in this trivial to fix anyway.  And I would hope the the
newer export.hpp is simpler than the current one is which
is way overly complex.  I just had to keep making it more
elaborate as each compiler was added in.  Factoring out
some of this complexity into your "? library" would be
a significant benefit from where I stand.

>> c) re-work the test to cover the new header order

> Although I don't mind doing c), I would appreciate it if you'd rework
> the test yourself, before I start.

Hmm - I was just thinking the the header order in test_export.cpp would be
inverted.  This would break test_export until the new export.hpp was
in.  Again not big deal as far as I'm concerned since I don't think tests
are even being run on the HEAD right now.  If it turns out that more
needs to be done to make the test past, then that would be sort of
a red flag indicating that users would have to change all thier programs
(not just archive_class headers) which shouldn't be necessary if
I understand your proposal correctly.  Note that I'm also asuming
that no new information is added to the archive itself - which would
create quite a splash.

For this reason, (aside from the fact that serialization has more or less
exhausted its budget for testing resources).  I think this is better than
making a new test. It will verify the user code won't have to be changed.

Robert Ramey