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 it.
Oh, sorry; I didn't see it before. For anyone else interested in this, it's ticket #1708: http://svn.boost.org/trac/boost/ticket/1708
I wasn't aware that it broke anything in any other library. I don't know 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 circular dependency.
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 consequences
This is a regression in a *very* popular library. Such things are exactly why we have beta releases, and are cause for delaying a release further.
be checked into the release branch without having gone through all the testing on the trunk.
Shall I commit it to the trunk, then? - Doug