Boost logo

Boost :

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:

> I wasn't aware that it broke anything in any other library. I don't
> know
> what VTK is.

The Visualization ToolKit ( 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at