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
> >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
> 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,
> seem deficient.
It's all in the naming. When there is a verb in the imperative, it means
If not, it will confuse users.
I think that the naming rationale given in Meyers "Object oriented software
For example, would any of these functions return a copy or would they mutate
sort( X );
resize( C );
erase( X, ... );
they all describe an action/command and it is most natural that they mutate
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk