[boost] Re: Re: Re: string_algo Formal Review

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.
>
[snip]
>
> > 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
idea
> 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
course,
> 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
the
> 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
to
> keep a minimal but complete set of algorithms.)
>
On one hand I agree that std::string focus would keep the library very
clear.

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
without support.

I thought very detailed documentation, with examples for popular strings,
can partially offset increased complexity of the interface.

/Pavel