From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-20 01:13:09
On Sun, Oct 19, 2003 at 04:28:18PM -0400, Beman Dawes wrote:
> 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
> 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.
> I definitely think the string_algo interfaces should be revised to reduce
> the chance of misuse.
Looking the the list of techniques used by STL, only the last one is suitable for
string_algo. First two disallow chaining, which is IMHO an important feature.
One, quite important aspect of the string_algo algorithms is that they
are by nature mutating. So I think, that it is natural to assume, that the basic
variant does the mutation. Also, mutating algorithms tend to be more efficient,
therefore they should be used as a primary option.
A agree, that the "clue" is important, but isn't an existence of a _copy variant
also a kind of "clue".
Currently there is one convention used in the whole library. If this convention
would be explicitly stated in the docs and stressed enough, if could still be
In case that these arguments are not convincing enough, I would vote adding _inplace
to mutating variants, and removing _copy. But keep in mind, that such a convention
would lead unexperienced programmers to use less efficient variants of algorithms.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk