Re: [boost] another draft of the string algorithms

From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2001-08-16 16:06:55

Darin Adler wrote:
> A second cut at the library is in
> <http://groups.yahoo.com/group/boost/files/string_algorithm/> now.

Looks good to me as a first cut.
There will be many small functions in the future.  Therefore,
when reviewing this, we may want to define a process how we can
add more algorithms relatively quickly and painlessly without feeling
the need for a re-review.  So we actually review the process and
what's currently implemented as a design example.

>      type replacement_format;

What's that?

> Here are the names for some of Mike's additional proposed algorithms:
> 
>      size_type count(string, pattern);

Useful. (Possibly needs a definition that only non-overlapping
"pattern"s are counted in "string".)

>      void trim(string& [, characters to trim]);
>      void trim_beginning(string& [, characters to trim]);
>      void trim_end(string& [, characters to trim]);

I haven't felt an urgent need for these, yet.   Usage examples?
Also, trim* can be emulated by replace_first() or replace_all()
with a regular expression.  Furthermore, I wouldn't put in
a set of "default" characters to trim, because it will often
be dependent on a lot of issues.   Better let the programmer
decide consciously each time the function is called.

>      vector<string> split(string [, delimiter characters]);

Someone else already asked for an OutputIterator interface.
I second that (the added flexibility regarding the container
is worth the additional source code line at the caller).

>      string join(vector<string> [, string separator]);
>      string join(start iterator, end iterator [, string separator]);

The "iterator" variant is sufficient.

> Mike also proposed using all the above names for the "modify and return
> result" variants, and using <xxx>_in, as the name for the "modify in place"
>   variants.

I understand that there are a few functions where you have a design
choice between modify-in-place (pass by reference) and "return modification
result".  The only candidates in the above list are the trim* functions.
I'd like to see usage examples what interface is more convenient to
the programmer for this particular function.  At the moment, I favour
modify-in-place.

In general, there should be only *one* variant, and not several with
or without _in suffix.  Keep it simple.

Jens Maurer