From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-08-17 10:33:45
At 08:52 PM 8/16/2001, John Max Skaller wrote:
> The problem is, the submittors do not know if the
>rest of the committee will want to change the interface.
> For example: I will recommend against mutators for
>tuples. Is the tuples author going to remove mutability
>just because of that? Who knows if the committee as a whole
>will agree with me or not?
> Historically, a LOT of interface details of
>libraries have been changed.
While that was certainly true in the past, I'm not sure it will be as true
in the future.
In the past, most of the libraries did not already exist. They were just
proposals, often for new designs, often done at the explicit request of the
committee, and usually without implementations. They often relied on core
language features which had never been implemented either. Even the STL
implementation from HP was not publicly available at the time the committee
voted to accept the proposal.
Those factors (which led to a lot of changes in the proposals) just aren't
present with the Boost libraries, which are just plain a lot more mature
than the material the committee had to work with in the past. Ensuring
proposals were for mature, existing-practice libraries was a major goal and
motivation for starting Boost.
Also remember that quite a few of the members of the LWG who might
otherwise propose interface changes are already participating in Boost and
have already suggested interface changes they believe are important.
> That is, you can be sure
>that every submission is going to be changed!
>The best example is the string class or iostreams.
>Both changed _substantially_ (mainly due to STL,
>but that wasn't the only factor).
> In particular, core language support for
>tuples is likely to radically alter not just the
>tuples library, but a whole lot of other high
>level meta-programming libraries. But that support
>doesn't yet exist. I think you just have to consider
>boost libraries a starting point for development.
Remember that the Technical Report is for the library. That means that
except in exceptional circumstances (threads?), it won't contain core
> Perhaps Beman can describe better the kinds
>of things the LWG does to libraries over time.
What I think fairly likely is that the LWG will put some of the Boost
libraries in existing headers, will change the names of some headers,
classes, and functions.
Some functionality may be struck, particularly if a library provides two
ways of doing the same thing.
But I'm really not expecting wholesale changes in signatures or semantics.
> Did you see 'auto_ptr'? Did you know
>I proposed that class,
Well, the actual proposal accepted by the committee was N0555, "Exception
Safe Smart Pointers", by Greg Colvin. It acknowledged "John Skaller, Steve
Rumbsy, Mark Terribile, and others have suggested similar templates..."
> and that the semantics
>were utterly different: it was designed
>to simply make
> T * x
>on the stack exception safe. noncopyable.
>non assignable. Just a holder that made stacked
>pointers look like ordinary auto objects.
>[That's why it's called 'auto' ptr]
That portion of the proposal eventually became the current
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk