From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-03-13 01:19:44
> > > 2. Nothing prevent usage of the library. It's accessible. And in
> > > this particular case I noticed several support request in users ML
> While I agree that this is technically true, in the commercial world the
> politics matter -- and being an 'add-in' boost library makes it difficult
> handle. I also believe it limits seriously the audience that will look at
> library because my perception is that most boost users don't mess with the
> sandbox or CVS -- they use the releases and that's it.
I really believe we need to remedy this situation. I would love to use
BOOST_FOREACH in my work projects, but end up writing my own
> Filesystem is another evolving library
> -- it solves real problems for many current users, but it doesn't do
> everything people want. Many of the changes are usage and user driven as
> Beman evolves the library interfaces. Some of the eventual changes are
> that were known at the time of the review. Just as another example, I
> boost.threads needs a full do over, but that doesn't make it any less
> for those that can make use of the library as it is and boost would be
> for it's absence.
I believe in both above examples there were no major unresolved issues
revealed during review. Fixing issues is natural part of library lifecycle
whatever big changes involved.
> Much of this library future has to do with the nature of the author. One
> unstated evaluation criteria is the 'behavior' of the library author. The
> author must understand the domain, be ready to take criticism with grace,
> move the work forward. If I didn't think Andreas is willing and up to
> task I would have voted to reject...
It's your call. I did not follow the discussion that close.
> In fact, 98% of the time
> when I'm writing a program I could care less about the traits template
> parameter and the other failings of std::string.
Just grep in boost and see in how name places libraries adding this
parameter. And you (and I and vast majority of C++ community) never need it.
> BTW, I don't think I've
> seen a proposal that identifies and eliminates all the std::string
issues -- I
> suspect that's because it's very difficult to balance the entire design
> for strings in a single interface.
For some time now I think we need boost::string. I hope upcoming reviews
will cover this area (at least partially).
> Anyway, while I think there are interesting directions that can be pursued
> expand the contribution base via the sandbox, we would need significant
> in my opinion, to pursue these. And, in fact, perhaps we would want this
> be a different organization from boost to make it clear that these aren't
> reviewed boost libraries.
As usual we just need volunteers to do the job ;)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk