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
> > 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk