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?). Yuval