From: David Abrahams (dave_at_[hidden])
Date: 2007-08-08 09:46:37
on Wed Aug 08 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
> Joe Gottman wrote:
>> changes to the other classes that would not break most clients will
>> break the serialization code: for example if a class adds a new
>> data member and a constructor with an extra parameter to initialize
> This is not a problem.
> The serialization library will no have any new serialization
> implementations. In the future, all serialization implementations
> have been part of the library which defines the type. It has been
> this way in the begining for data-time, multi-indexe, ranges? and
> I'm sure a number of others. So it would seem that I'm only stuck
> with the stl and a couple of others like shared_ptr and variant.
> But its not even that bad. STL isn't expected to change, and
> Matthias Troyer has continued necessary refinements for collections
> so that leaves just a couple to keep me honest.
Then, as with the Python library, we have the opposite problem: most
other libraries are dependent upon Serialization.
In reality, python bindings and serialization code are separable and
optional parts, and we ought to have some way to treat them as such
from the point of view of the testing and release processes.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk