Re: [Boost-users] [string_algo]find_head/find_tail additions

From: Pavol Droba (droba_at_[hidden])
Date: 2005-12-03 02:27:15

On Sat, Dec 03, 2005 at 01:21:43AM +0200, Yuval Ronen wrote:
> Pavol Droba wrote:
> > On Fri, Dec 02, 2005 at 07:47:16AM +0000, Martin wrote:
> > 
> >>What's wrong with erase_tail_copy?
> > 
> > 
> > Well, you got me. It's a shame, but I have forgotten, that there is already 
> > function for this. My response was make without consideration of the existence
> > of erase_tail/head.
> > 
> > Given this, I see no futher reason to modify behaviour of find_head.
> 
> I took a look at erase_tail_copy and it seems it's not exactly what I 
> want. The erase_tail_copy is considered a mutating function in this 
> library and therefor requires a SequenceT as an input, rather than a 
> RangeT (no string literals allowed). It also makes a copy of the input 
> string when I don't think there's any need to.
> 
> In other words, those erase_xxx_copy functions are, IMO, misplaced. No 
> wonder I couldn't find them in the first place... I think they are 
> essentially find algorithms just like the find_head/find_tail functions, 
> and should:
> 1. Be named find_something, not erase_something
> 2. Placed in the find.hpp header, not erase.hpp
> 3. Accept RangeT (including string literals)
> 4. Return an iterator_range just like the find_xxx functions, without 
> making copies (of course there could also be _copy versions, but on the 
> other hand, do the find_xxx functions have _copy versions?).
> 

erase_tail_copy does not exactly be what a find_head would. But it is quite close.
The only serious diference is, that it does not return an iterator_range based
reference to the input string, rather a copy of it.
This might be a serious problem, however I have not yet come to a situation
were it realy mattered. On the other hand, my personal experience does not prove
anything globaly.

The definition and placement of erase_tail_copy is consistent with other erase_xxx algorithms,
it should not be changed. Therefore the only reasonable way to provide the exact
functionality as you requested is to modify find_head (or add find_head_but).
If we are going this way I'm biased to provide negative-index variant, due
to similarities with scripting languages.

At the end, I feel, that it would do no wrong to extend find_head/tail and then probably
also find_nth with the support for negative indexes. So, when I get a chance, I'll implenet it.

Regards,
Pavol

BTW: 
   find_xxx functions does not need to have copy variants, since they are not mutating
   algorithms. Find simply returns a reference to a input string. It is up to you
   what to do with it. One possility is to make a copy.
   In mutating algorithms like replace and erase, there is fundamental difference
   how algorithm behaves in mutable and copy version.