Re: Report from Redmond

From: williamkempf_at_[hidden]
Date: 2001-10-29 11:27:15

--- In boost_at_y..., mda_at_d... wrote:
> --- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> >  >if the latter, i can understand why the boost threads library
> >  >was brought up. if the former, i don't -- that library has
> >  >to my knowledge yet to appear in a boost release, and has not
> >  >completed the boost internal process, to the extent that
> >  >has been formalized.
> > 
> > Boost.threads has passed formal review and is in the latest 
> release.  Plus 
> > Bill Kempf was available to present it to the LWG in person.
> 
> ah, yes, i now see it is in 1_25 (in fact its test directory takes
> more than 1Mbyte by itself...)

Huh?  The test directory has 2 files, Jamfile at < 1KB and 
test_thread.cpp at 12KB.  That's a max of 13KB which is a far sight 
from 1MB.  In fact, the entire boost\libs\thread directory tree takes 
only 314KB including CVS cruft (so the release in Zip format should 
be even smaller).

> it was not however in 1_24.
> so it has been in a release for a month.

Very true.

> i've got nothing in particular against bill nor against the
> boost thread library -- i don't know either.
> i'm just thinking from my general experience that every API
> i've ever designed changed considerably by the time i'd
> shipped a product or two with it.

Yes, but with out trying to speak for the committee (which I can't 
do) that's precisely why it's important to start considering such a 
library.  Before it can actually be accepted and standardized there's 
going to have to be a lot of feedback from library implementors in 
order to insure that a threading library meets the needs of 
everyone.  Don't confuse the interest in the library given by the 
committee as a final acceptance.  No new libraries have been accepted 
yet.
 
> the only thing i can think of which is more controversial
> and complicated than threading is gui toolkits.
> i just can't believe that a few months of "shakeout" time is enough
> to understand the implications of any particular threading 
> api proposal.

"Shakeout" generally speaks more to the implementation then to the 
design, which is less interesting for the standard.  Otherwise, 
you're quite correct here.
 
Bill Kempf