Re: [boost] [Serialization] [1.36.0] extended_type_info_typeid::destroyshould use boost::serialization::access

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  
> 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