Re: [boost] Re: [string algo formal review]

From: Rob Stewart (stewart_at_[hidden])
Date: 2003-11-03 12:45:18

From: Pavol Droba <droba_at_[hidden]>
> On Fri, Oct 31, 2003 at 03:39:26PM -0500, Rob Stewart wrote:
> 
> > Too bad.  You're convinced you're right and it's your library, so
> > do what you want.  That doesn't fix the problem, however.
> 
> There are other people, who thinks that 0-based index here is right. 

Just as there are those convinced it isn't.

> I don't think that it is possible to satisfy everyone. 1-based index 
> bring more confusion then benefits in my point of view.

That's why I said, "it's your library, so do what you want."
Given that, you might wonder why I continue to discuss the
matter.  It is to try -- vainly, perhaps -- to reveal the flaw I
see in your arguments.  I don't want you to make a decision based
upon what I consider to be incorrect or incomplete information.

> It adds an undefined value of 0, it is counterintuitive from the perspective
> of common C convention. Proposals on the naming change were not better,

I can't argue that there is an issue in making 0 an undefined
value, but then again, so are negative numbers (should a user not
get or notice compiler warnings about mixing signed and
unsigned).

You continuously return to the vacuous "it is counterintuitive
from the perspective of common C convention" argument.  That
conventional use of 0 applies to indexes, is not under dispute.
However, if one doesn't recognize the use of an index, then one
won't *necessarily* expect to use 0.  I know full well that
indexes count from 1 in C/C++.  That doesn't mean I expect every
numeric argument to every function to count from 0.

The *_nth functions lead to that problem for at least some.

> than the current one (given the fact that they solved the index problem,
> but usualy brings other form of confusion).

That may well be the case, but that form of confusion is less
likely to trip fingers repeatedly -- "Arrgghh!  Will I *ever*
remember that find_nth() counts from 0!" -- than is the
off-by-one problem.  That is, it will be easier to remember that,
for example, "index" is the name of the function that returns the
nth substring from a "string" than that the "1th" substring is
the second.  (It's been years since I've used BASIC, but I
remember index(), for example.)

> Until now, the only acceptable suggestion, that was consistent, was to 
> remove *_nt variants in favor to find_iterator (currently under development).
> Although it would be less powerful, but it is quite possible, that the 
> usability of *_nth algorithms is limited anyway.

That would be more consistent with the iterator/algorithms view
of the STL and would get us out of this quagmire.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;