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

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-28 02:21:09

On Tue, Oct 28, 2003 at 12:33:54AM +1100, Thorsten Ottosen wrote:
> 
> 
> "Pavol Droba" <droba_at_[hidden]> wrote in message
> news:20031026155020.GG17011_at_lenin.felcer.sk...
> > On Mon, Oct 27, 2003 at 02:07:47AM +1100, Thorsten Ottosen wrote:
> 
> > > You also called your functions firnd_first, not find_0th, and we have
> > >
> > > find_first( s, XX ) == find_nth( s, XX, 0 )
> > >
> > > which doesn't seem natural. It's like having an integer variable and
> > > making
> > > zero mean you have got one
> > > of something.
> > >
> >
> > What would then denote find_nth( s, XX, 0 )? Should it throw an exception?
> 
> a good idea. the argument could be an int and you could prevent [-max_int,0]
> as input.
> There's been some heated discussion once in a while, but I still don't get
> that one would like to
> use unsigned types.

Actualy it is very bad idea, to replace compile-time checking with a run-time one.
And I have absolutely on idea why "int" is better than "unsigned int" in this case.

Why whould one want to use unsigned types? Because the negative values are not permited
here and so "unsigned" denotes a valid domain. Its i a strong compile time check.
 
> > Why would you use
> >
> > for( unsigned int i=1; i<=n; i++ )
> > {
> > // do something with
> > find_nth( s, XX, i );
> > }
> >
> >
> > and
> >
> > for( unsigned int i=0; i<n; i++ )
> > {
> > vector[i] = i;
> > }
> >
> > ?
> 
> I don't see the similarity between the two examples. One is *searching* for
> substrings another
> is merely *accessing* a random access container at index i. It's not obvious
> at all that these have anything in common;
> So I merely asking for a good explanation :-)

In C the convetion is that all indexes should be 0-based. This implies that
all cycles will be <0,n) (0 included, n not). This simplyfy the checking of the
code, because bondary conditions are always most error prone.

Matching substrings also form a sequence, indexable by find_nth. It is exactly
the same as an array, where you use operator[] to index elements.

There is no fundamental difference between these two structures so there in 
absolutely no reason to chance indexing convention.

Actualy, why do you think, that FIRST element in the array has an index 0?

> >
> > It is one of most basic conventions in C programing, that first element
> > has
> > the index 0.
> > Whatever are your reasons, but you want want to break something very
> > fundamental.
> > 
> I don't know. It's like making the 1st of december into the 0th of december
> AFAICT. I don't suppose date libraries do that.
> 

1st december is always a 1st december, but if you  have a list of days in the december,
an element representing December the 1st will have an index 0. I don't see anything
unnatural here.

If you count days, today always counts as a day 0, tommorow is a day 1 and etc.

> > I'm against anything which would imply some explicit affinity to
> > std::string.
> >
> > I'm not against improvements to the iterator_range, but only with a
> > respect
> > to an arbitrary container.
> >
> > We can call it substring, but only in terms of the string definition, I
> > have already
> > mentioned. Everything else is a hack.
> >
> > So you most probably will not convince me to prefer std::basic_string in
> > the context
> > of this library. It would break the basic properties of the design.
> 

[a substring example...]

There is very big difference between the substring you have presented and the iterator_range.
I'm not saying that the substring class is useless, but it should be used for a different purpose.

Propably most significant purpose of the iterator_range in the string_algo library is to
hold a result from the find() operation.

You are argumenting that it is inconvinient to convert the result of this operation to
a string. But you have probably not understood the purpose of find() algorithm.

Why do you need to convert a result from f.e. find_first( str1, "abc" ) to a string?
You don't need to use find(), to get this result, because it is obiously "abc".
Purpose of find() is to look for a part of the sequence which has the required criterium,
IOW to find pointers to the original sequence so, that some operation requiring this
info can be executed ( like splitting, erasing or transformation ).

When you convert an iterator_range to a string, you loose this information. And actualy,
it is the only information which is realy relevant with the respet to iterator_range.

Therefore I thing, that the explicit conversion using either copy_range or, container_cast (which
I have proposed in a previous mail) is quite sufficient in respect to the iterator_range.

Regards,

Pavol