[boost] Re: Library versioning

From: Herb Sutter (hsutter_at_[hidden])
Date: 1999-12-21 11:11:41

Good points, Bill, particularly on the effects of adding new components. I look
forward to others' responses, but let me address your last paragraph:

>Finally I don't believe boost needs to be nearly as "stable" as the standard
>library.  I would hope that boost changes several times a year, and I'm not
>bothered too much when some of those changes aren't backward compatible.
>The standard library will not have significant changes more than once a
>decade, and almost all of those should preserve compatibility.  The theory
                                 ^^^^^^
s/should/must/ That, right there, is the problem.

For example, two months ago in Kona, virtually every committee member agreed
that vector<bool> was underspecified and just plain broken, and that the only
major ways to fix the problem(s) were to loosen the container requirements
(impossible, would break lots of code) or somehow remove/rename vector<bool>.
Virtually everyone agreed, but nothing was done principally because we have not
yet come up with an agreed-upon strategy for how to change the blankety-blank
standard library.

Hence my strong interest in this regard; vector<bool> is broken but relatively
unimportant and despite my words I don't care much about it individually. I DO
care about the fact that we don't know how we plan to rev the library, and
therefore I DO use vector<bool> as a whipping boy to force discussion about how
we would do this -- but the main issue must remain the general case. Once we
know what we want to do in the general case, we can go ahead and do what we all
already agree is the right thing to do (we just don't know the details of how)
in specific cases like vector<bool>.

>is that stuff won't make it into the standard until it has survived
>substantial real-world abuse.  The bar should not be that high
>for boost.

True in itself, but I hope BOOST will continue its function to "establish
existing practice" -- and this is a place where we desperately need existing
practice, or at least informed discussion. As long as the solution is not too
onerous in practice for BOOST it could actually be implemented, but it would
certainly be wonderful if we could at least hash out (pun intended) what a
viable approach would indeed look like.

Herb