Re: [boost] Technical session at the October C++ meeting?

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 
language changes.

 >	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::scoped_ptr.

--Beman