Re: [boost] Re: string_algo Formal Review

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-23 14:21:07

On Thu, Oct 23, 2003 at 07:35:04PM +0300, Peter Dimov wrote:

[snip]
 
> This request, in its simplest form, translates to
> 
>     bool isspace(std::string const & s);
> 
> This is what users want.
> 
> You can decide to make it more generic if the increased power is worth the
> price, adding a std::locale parameter to match std::isspace, templatizing on
> the character type, generalizing to is_classified, generalizing to arbitrary
> sequences and arbitrary predicates, and finally generalizing to a range
> (pair of iterators).

all() in combination with classification predicates have all properties
you have specified and more. It works for an arbitrary container, character type
and predicate. Locales can be explicitly specified in the construction 
of a classification predicate.

A range (or a pair of iterators) is a deprecated interface in this library.
Current interface has the same power as a range, but it is much more convinient to use.

You can write:

all( std::string("abc"), is_lower<char>() );
all( "abc", is_lower<char>() );

vector<char> v;
v.push_back('a');v.push_back('b');
all( v, is_any_of<char>("abc") );

and when you realy need to specify a pair of iterators, you can use iterator_range
or std::pair to encapsulate them and write:

all( make_range( Begin, End ), is_space<char>( CustomLoc );

> 
> You can "draw the line" anywhere in between. You have decided to provide
> 'all' but stopped short of 'find_if_not'.
> 

To be honest, I don't know what are you missing from the current implementation of all(),
and in what way it is less effective or less powerful to find_if_not?

> [...]
> 
> > Last point is, why the string_algo supports more different containers.
> > String processing is not only a matter of std::string. There are
> > other essential structures, for instance C-string.
> > It would be possible to constraint the library to std::string, but
> > what benefit it would bring over the current design?
> >
> > Imagine a function:
> >
> > replace_first( Input, Substring, Replacement );
> >
> > Under the current design, you can use any container for each of
> > parameter. It can be even char*, or char[]. It can be a unicode a
> > vector or anything else satisfying the requirements.
> >
> > You are suggesting this
> >
> > replace_first( const std::basic_string<>& Input, std::basic_string<>&
> > Substring, std::basic_string<>& Replacement );
> >
> > Eigher you povide additional oveloads for at least char* and wchar*,
> > it this interace is very limited.
> 
> The interesting thing is that I would not object to your strawman generic
> 
>     void replace_first( String, Substring, Replacement );
> 
> that works on "anything" since
> 
> 1. A generic replace_first does everything the non-generic version would do,
> and more, and I, as the user, need not pay anything for the increased
> functionality;

And what do you consider as a "payment". This library was designed to not compromise
performance in any way. Actualy for std::string, implementation internaly
calls .replace method.
 
> 2. It is fairly natural for replace_first() to be a mutating operation;

it is also in mutating version.

> and
> 
> 3. There is no general algorithm disguised as a string processing function
> lurking underneath replace_first.

I can imagine many possible usage scenarios for replace_first, but still,
the string processing is the most obvoius one. Actualy before I even started
the developmnet of this library, there were already some discussions and
experiments regarding the string algorithms. replace_first was one on the
core algorithms.

> This only goes to highlights my concerns that "algorithm bundles" aren't
> well suited for review as one monolithic "take it or leave it" piece.
> 

This library is a bundle of algorithms. But besides to algorithms, it also
introduces several new algorithm concepts into boost. It is highly probable,
that some of these concepts will be adopted by the future algorithm libraries.

If there are some serious reasons why some specific part of this library is
deficient and that it should not be a part of this library, there is no
problem to remove it and accept the library without it. The library is
a set of algorithms. Except of some core components, all parts are selfcontained.

But in my opinion, it seem strange to request a removal of algorithms, just because
they are not 100% string related, when they are useful, and there is currently
no viable alternative.

Regards,

Pavol