Boost logo

Boost :

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
> <> 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

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

Jens Maurer

Boost list run by bdawes at, gregod at, cpdaniel at, john at