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

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-28 05:44:41

On Tue, Oct 28, 2003 at 08:17:34PM +1100, Thorsten Ottosen wrote:
> "Pavol Droba" <droba_at_[hidden]> wrote in message
> news:20031028072108.GN4718_at_lenin.felcer.sk...
> 
> > > > 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.
> > 
> what's the compile time check? AFAICT,
> 
> int i = -2;
> ...
> find_nth( s, i );
> 
> compiles just fine.

The compiler should issue you at least a warning.
 
> > And I have absolutely on idea why "int" is better than "unsigned int" in
> > this case.
> > 
> AFAICT, unsigned types are for bit manipulation (and confusion), not much
> else.
> 
> I'll like the library to be easy to use. If I use an int, I have to make the
> make the cast myself:
> 
> find_nth( s, numeric_cast<unsigned>( i ) );
> 
> I think the library should make that check for me.

You should not use an "int" ... 

Index is a positived integer, so it is denoted by an "unsigned" number, what it
wrong with this and why do you want to use int instead?

Sorry, I don't have any more arguments for this except those that I have stated.

> > 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.
> > 
> no, its an implicit conversion with surprising results. Some compilers might
> warn, some might not.
> 
> > 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.
> > 
> you're not "indexing", you're "searching".

I'm indexing! I'm indexing the matching subtrings. If you are talking about
the n-th matching substring, you are refering to an element in the ordered set,
therefore you are talking about the index of it.
 
> > There is no fundamental difference between these two structures so there
> > in
> > absolutely no reason to chance indexing convention.
> > 
> I certainly think there is a difference between indexing and searching; one
> is that
> indexing takes constant time, and searching does not.

Searching is only an operation which makes possible to identify elements
of "an ordered set of all matching substring". Refering to a concreate
element of this set with a number is called indexing.
 
[snip]

> > Propably most significant purpose of the iterator_range in the string_algo
> > library is to
> > hold a result from the find() operation.
> > 
> the purpose of a more domain specific abstraction could be to also allow for
> seemless integration
> of the found substring with other strings.
> 
> > 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".
> > 
> the example is made up. just image the its a regular expression.

This example is not made up. Even for regular expression, the real
reference to the original container is most important ...
 
> > 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 ).
> > 
> and this task could still be done wither either a substring or an iterator
> range or just std::pair.
>
 
It could not be done with a substring, because it depends on the underlying container.
This is a strong contraint, that iterator_range does not have.

And yes, std::pair could be used, but iterator_range provide an
interface which is more suitable for this purpose.

> > 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.
> > 
> sometimes you just don't know what you've found and you might wanto store it
> in a string and throw the source away.

You could, and if this rare scenarion you can use copy_range of container_cast.
But you should be aware, that you are throwing away a relevant part of
information so it does make sense to make this operation explicit.

> 
> > 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.
> > 
> As you  might have seen, the the basic_substring template did not allow for
> implicit conversion to string, but
> it did give the implicit conversion to (safe)bool.
> 
I have already said, that conversion to save-bool can be considered.

Regards,

Pavol