Re: [boost] another draft of the string algorithms

From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2001-08-17 16:14:13

Darin Adler wrote:
> On Thursday, August 16, 2001, at 02:06  PM, Jens Maurer wrote:
> >>      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.
> 
> Trimming spaces off the beginning and/or end of a string is the main place
> this comes up. The tricky bit is deciding what definition of "space" to
> use. It's not clear what kind of data structure should be used for the
> "characters to trim" predicate.

Ok, Beman gave a few examples as well.

I'm still thinking of the string algorithm library as being "simple",
possibly just 5-line-wrappers around <algorithm>.  Therefore,
I'd say we should use a null-terminated string of [wide] characters
which are to be trimmed. (see std::string::find_first_not_of).
 
> Perhaps, but I think this has been subject to much debate. Some
> programmers find this:
> 
>         vector<string> groups(get_groups());
>         cout << join(groups.begin(), groups.end(), ", ");
> 
> significantly inferior to this:
> 
>         cout << join(get_groups(), ", ");
> 
> It's true that the iterators provide a solid basis for algorithms that are
> truly generic, but they can be inconvenient to work with.

Keep it simple: Don't redesign the STL, don't introduce funny
intermediate types which don't work with the rest of the STL.
And don't wait for boost::vector<> to materialize.

"join" is so useful compared to writing the loop yourself that
people can write their own one-line-wrapper if they really
want to save the one source code line with the temporary
variable.

> >  The only candidates in the above list are the trim* functions.
> 
> I think that erase_first, erase_all, replace_first, replace, and
> replace_all are also candidates.

They weren't in my list :-)
But I agree they are candidates.

> > 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.
> 
> I have considerable experience with both versions of "replace", and I find
> the "return modification result" flavor to be far more convenient for my
> coding style. I think I've been using a more functional style with fewer
> local variables since I read the _Refactoring_ book, which may explain
> this.

Ok.  Except that std::string is designed to "modify in place", e.g.
it has lots of modifying member functions.  And that could potentially
be more efficient, because it saves useless copies.  String copies
require a dynamic memory allocation, so they're possibly expensive.

Jens Maurer