From: Doug Gregor (dgregor_at_[hidden])
Date: 2008-07-28 15:56:40
On Jul 28, 2008, at 4:36 PM, Robert Ramey wrote:
> I've been aware of this for sometime. There is a Trak item open on
Oh, sorry; I didn't see it before. For anyone else interested in this,
it's ticket #1708:
> I wasn't aware that it broke anything in any other library. I don't
> what VTK is.
The Visualization ToolKit (http://www.vtk.org/). It's an open-source
library for scientific visualization that's quite popular. The part
that's actually relying on Boost.Serialization isn't widely used yet,
but fixing the problem means taking a much more widely-used class and
making its destructor public... they're not going to be too happy with
me if I do that, especially because this code used to work with 1.35.0.
> I did take a look at it when it was reported and concluded that
> the obvious fix might have more subtle implications than first met
> the eye, so I left it pending on purpose. For example, the proposed
> fix creates a circular dependency between extended_type_info
> and serialization whereas before serialization depended on
> extended_type_info and not the other way around.
Well, "access" is a pretty basic facility, and all of this code is
part of the serialization library. If extended_type_info were part of
a completely separate library, I'd be more concerned about the
> So, though I'm interested in seeing the situation addressed,
> I'm not convinced that this is a good way to do it.
> Also, it is too late to checkin changes to release branch which
> is already late and should be released ASAP. And I would
> never recommend that some change with possible unintended
This is a regression in a *very* popular library. Such things are
exactly why we have beta releases, and are cause for delaying a
> be checked into the release branch
> without having gone through all the testing on the trunk.
Shall I commit it to the trunk, then?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk