From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2003-10-22 17:33:16
"Peter Dimov" <pdimov_at_[hidden]> wrote
> >> Part of the problem is that the library isn't really a string
> >> algorithm library, it's a container algorithm library with
> >> string-like operations.
> > What to do with people who use Alexandrescu's flex_string<> or other?
> Nothing? With all due respect, I estimate the number of people using
> flex_string<> and needing 'all' as close to zero. A line needs to be drawn
> somewhere; it is this line that separates ivory tower "might be a good
> if" code from useful libraries that have a clear goal.
> All-encompassing "algorithm" libraries (of MPL scope, say) are a fairly
> special case and as such aren't handled very well by the Boost review
> process. A simplified "std::basic_string convenience functions" component
> will be more likely to pass review without much trouble - except, of
> the functional vs in place debate.
> For the "but what about people that use other character sequences" case, a
> separate library of supporting algorithms may be more appropriate, where
> focus would be seamless STL integration, perhaps with the algorithms being
> submitted one by one and reviewed on a case by case basis (the goal being
> keep a minimal but complete set of algorithms.)
On one hand I agree that std::string focus would keep the library very
OTOH there are way too many strings around (I worked with CString, Qt
string, wxString, flex_string, AnsiString, BSTR, Corba string and few
home-made ones) and these would be de-facto excluded. Legacy code would be
I thought very detailed documentation, with examples for popular strings,
can partially offset increased complexity of the interface.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk