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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-10-28 04:17:34

"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.

> 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.

> 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".

> 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.

> > > 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.

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.

> 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.

> 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.

> 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.

-Thorsten