[boost] Re: Re: string algorithms review

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-10-20 09:39:05

From: "Beman Dawes" <bdawes_at_[hidden]>
> At 09:06 AM 10/19/2003, Thorsten Ottosen wrote:
>
>  >C++ is not a pure functional language and inplace mutating algorithms
are
>  >all over the place.
>  >
>  >I don't have more to say about this; I acknowledge that you have a
>  >different view and I agree it would be nice to hear other people's
> opinion.
>
> Like Daniel, I'm also concerned that some of the string_algo mutating
> functions may be error prone.
>
> It isn't just that these functions are mutating. It is that they mutate
> their inputs without giving users much of a clue.
>
> For example, the current Standard Library mutating algorithms [25.2] use
> three techniques which tend to alert users to their mutating nature:
>
>     12 have "result" arguments
>     12 have void returns
>      7 add "_copy" to the name
>
> Four use more than one of the above techniques.
>
> When looked at from that perspective, the std mutating functions which
> don't offer some form of clue (remove, unique, partition,
stable_partitiou)
> seem deficient.

It's all in the naming. When there is a verb in the imperative, it means
mutation.
If not, it will confuse users.

I think that the naming rationale given in Meyers "Object oriented software
construction" is
very good.

For example, would any of these functions return a copy or would they mutate
the input?:

sort( X );
resize( C );
erase( X, ... );

they all describe an action/command and it is most natural that they mutate
the input.

> I definitely think the string_algo interfaces should be revised to reduce
> the chance of misuse.

(As suggested in this thread) having a proxy return type would remove the
particular misuse you all dislike
and chaining can still be allowed. I would suspect that the overhead (if
any) from the proxy object
would be small compared to the rest of the work done by the algorithm.

This would AFAICT give the *best* default:

(1) its efficient,
(2) no ambiguity/misuse
(3) allows for chaining
(4) makes the function name meaningful
(5) makes the default work with char arrays (copy doesn't work here)
(6) makes naming consistent with STL

I took a look at how other languages do trimming:

php:       trim() does not modify the original.
python:  strip() does not modify the original
java:      trim() : does not modify the original ( even though it's a member
function; there's no equivalent in StringBuffer )
eiffel:     prune() : mutates
perl:      chomp: mutates

best regards

Thorsten