From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-10-28 04:17:34
"Pavol Droba" <droba_at_[hidden]> wrote in message
> > > What would then denote find_nth( s, XX, 0 )? Should it throw an
> > a good idea. the argument could be an int and you could prevent
> > as input.
> > There's been some heated discussion once in a while, but I still don't
> > that one would like to
> > use unsigned types.
> Actualy it is very bad idea, to replace compile-time checking with a
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
AFAICT, unsigned types are for bit manipulation (and confusion), not much
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
> here and so "unsigned" denotes a valid domain. Its i a strong compile time
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
> 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
> absolutely no reason to chance indexing convention.
I certainly think there is a difference between indexing and searching; one
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,
> > > have already
> > > mentioned. Everything else is a hack.
> > >
> > > So you most probably will not convince me to prefer std::basic_string
> > > 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
> 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
of the found substring with other strings.
> You are argumenting that it is inconvinient to convert the result of this
> a string. But you have probably not understood the purpose of find()
> Why do you need to convert a result from f.e. find_first( str1, "abc" ) to
> You don't need to use find(), to get this result, because it is obiously
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
> IOW to find pointers to the original sequence so, that some operation
> 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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk