headers
Yuval Ronen | 1 Dec 2005 10:54
Picon
Favicon

[string_algo] find_head/find_tail additions

Hi.

I have a feature I would like to see in the string algo library.
The present find_head function gets an unsigned int N and returns the 
head of the input string with size is at most N. I would like another 
option that will return the head of the input with size at most 
original_size minus N. In other words, all the string without the last N 
characters. if original_size < N the return would be an empty string.

The interface for such a functionality might introduce a new function 
(find_head_but()?), or make the present find_head function accept a 
signed int N, instead of unsigned int, with a negetive number indicates 
the new functionality.

And of course the same for find_tail.

Thanks,
Yuval
Permalink | Reply |
headers
Pavol Droba | 1 Dec 2005 13:11
Picon

Re: [string_algo] find_head/find_tail additions

Hi,

This seems like a goot idea. I like the interface with int parameter.
I'll add it to my todo list.

Thanks,
Pavol

On Thu, Dec 01, 2005 at 11:54:38AM +0200, Yuval Ronen wrote:
> Hi.
> 
> I have a feature I would like to see in the string algo library.
> The present find_head function gets an unsigned int N and returns the 
> head of the input string with size is at most N. I would like another 
> option that will return the head of the input with size at most 
> original_size minus N. In other words, all the string without the last N 
> characters. if original_size < N the return would be an empty string.
> 
> The interface for such a functionality might introduce a new function 
> (find_head_but()?), or make the present find_head function accept a 
> signed int N, instead of unsigned int, with a negetive number indicates 
> the new functionality.
> 
> And of course the same for find_tail.
> 
> Thanks,
> Yuval
> 
> _______________________________________________
> Boost-users mailing list
(Continue reading)

Permalink | Reply |
headers
Martin | 2 Dec 2005 08:47
Picon

Re: [string_algo]find_head/find_tail additions

Pavol Droba <droba <at> topmail.sk> writes:

> 
> Hi,
> 
> This seems like a goot idea. I like the interface with int parameter.
> I'll add it to my todo list.
> 
> Thanks,
> Pavol

What's wrong with erase_tail_copy?

Don't like the idea with negative numbers becuse I can't see how code can use 
the functionality. Either you want the to use the positive version or the 
negative version and then it can be different functions. Combining it into the 
same function doubles the size and might affect inlining, optimization etc.

What about find_nth?
Permalink | Reply |
headers
Pavol Droba | 2 Dec 2005 09:05
Picon

Re: [string_algo]find_head/find_tail additions

On Fri, Dec 02, 2005 at 07:47:16AM +0000, Martin wrote:
> Pavol Droba <droba <at> topmail.sk> writes:
> 
> > 
> > Hi,
> > 
> > This seems like a goot idea. I like the interface with int parameter.
> > I'll add it to my todo list.
> > 
> > Thanks,
> > Pavol
> 
> 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.

> 
> Don't like the idea with negative numbers becuse I can't see how code can use 
> the functionality. Either you want the to use the positive version or the 
> negative version and then it can be different functions. Combining it into the 
> same function doubles the size and might affect inlining, optimization etc.
> 

Actualy the usage of negative numbers in indexation of string ranges is quite common
in scripting world. For example ruby and perl do have something like this.
(Continue reading)

Permalink | Reply |
headers
Yuval Ronen | 3 Dec 2005 00:21
Picon
Favicon

Re: [string_algo]find_head/find_tail additions

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
(Continue reading)

Permalink | Reply |
headers
Pavol Droba | 3 Dec 2005 08:27
Picon

Re: [string_algo]find_head/find_tail additions

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?).
>
(Continue reading)

Permalink | Reply |
headers
Yuval Ronen | 3 Dec 2005 11:38
Picon
Favicon

Re: [string_algo]find_head/find_tail additions

>>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?).
>>
> 
> 
> The definition and placement of erase_tail_copy is consistent with other erase_xxx algorithms,
> it should not be changed. 
> 
> 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.

My point was that erase_tail_copy /can/, and therefor /should/, be
(Continue reading)

Permalink | Reply |
headers
Yuval Ronen | 1 Dec 2005 19:06
Picon
Favicon

Re: [string_algo] find_head/find_tail additions

Pavol Droba wrote:
> This seems like a goot idea. I like the interface with int parameter.
> I'll add it to my todo list.

First of all, thanks.

One problem with the negative numbers I just thought of: zero. A 
positive zero means return an empty string. A negative zero means return 
the whole input string. But since there's no difference between positive 
zero and negative zero...
Permalink | Reply |
headers
Pavol Droba | 1 Dec 2005 21:15
Picon

Re: [string_algo] find_head/find_tail additions

On Thu, Dec 01, 2005 at 08:06:14PM +0200, Yuval Ronen wrote:
> Pavol Droba wrote:
> > This seems like a goot idea. I like the interface with int parameter.
> > I'll add it to my todo list.
> 
> First of all, thanks.
> 
> One problem with the negative numbers I just thought of: zero. A 
> positive zero means return an empty string. A negative zero means return 
> the whole input string. But since there's no difference between positive 
> zero and negative zero...

Well, we just have to decide and document it. I think, that the safer
approach would be to treat 0 as positive number. If for nothing else,
it would not break current definition. 

Regards,
Pavol
Permalink | Reply |

Gmane