From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-25 16:31:05
On Sat, Oct 25, 2003 at 09:20:12PM +0100, Paul A. Bristow wrote:
> | -----Original Message-----
> | From: boost-bounces_at_[hidden]
> | [mailto:boost-bounces_at_[hidden]]On Behalf Of Pavol Droba
> | Sent: Friday, October 24, 2003 3:31 PM
> | To: Boost mailing list
> | Subject: Re: [boost] Re: string algorithms review
> | > 2 The suffix should be _copy and _copyto.
> | Why? Could you plese provide rationale for this.
> Because it is shorter and if the code is trim_copyto(s) is reads as though the
> 'to' means it goes to s.
what about meaning 'trim' the 'copy' -> trim_copy
> (Of course, a rational language would specify in, out, or in&out but I won't
> stir that hornets nest again!)
> But actually I really rather like Rob Stewart's trimmed' suggestion.
> std::string t(trimmed(s));
> or even if t already exists (poor but what novice and ex-C programmers may do)
> t = trimmed(s)
> seems to me to imply that nothing is done to s.
> But to_uppered(s) or uppered is not so nice, but still just OK?
> And what about concatentation t += trimmed(s);
> and addition string full_name = trimmed(forename) + substr( trimmed(surname); ?
> Since we already have protection against misuse,
> this seems quite attractive to me.
I have some counterarguments.
- It is possible to used _copy as a convention for every algorithm in the library.
- for trim and trim_copy, it is obvious, that they are variant of the same algorithm.
It is not so obvious for trim and trimmed.
- If we adopt the convention you are proposing, it could be quite chalenging
to makeup the names for algorithms like replace_first ( ?first_replaced? ) or even worse,
When names are concatenated from multiple words, adding a suffix, does not break anything,
- This convention is backedup by STL, so people are used to it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk