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

From: Rob Stewart (stewart_at_[hidden])
Date: 2003-10-27 10:49:03

From: Pavol Droba <droba_at_[hidden]>
> On Mon, Oct 27, 2003 at 02:07:47AM +1100, Thorsten Ottosen wrote:
> > "Pavol Droba" <droba_at_[hidden]> wrote in message
> > news:20031026141956.GD17011_at_lenin.felcer.sk...
> 
> > > Then you would also need a type which holds values in range 1..n. Arrays
> > > and
> > > containers are 0-indexed also because unsigned types are denoting exactly
> > > this
> > > domain. And actualy what conteptual difference between "first element" and
> > > "first match of substring"?
> > 
> > well, you almost said it The first element of an array is index 0. The first
> > substring of a string
> > is a index X. Also, array objects(chars). are not substrings unless we're
> > talking about substrings of lenght 1.
> > 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.

A substring is not a structural element of the container.  A
container is, by definition, composed of elements.  A substring
is a semantic notion temporarily associated with a portion of a
container.  Thus, the former should be denoted using the usual
C/C++ indexing notation.  The latter, OTOH, should be denoted
using the vernacular: we use ordinals to refer to things like
substrings.  That means numbering from one for substrings.

> What would then denote find_nth( s, XX, 0 )? Should it throw an exception?

Sure.

> 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;
> }
> 
> ?
> 
> 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.

It isn't breaking something fundamental to recognize that you're
comparing apples and oranges.

> > > > I find that too complicated to do really simple and frequent stuff.
> > > > That's
> > > > why I would like to
> > > > see substring concept.
> > >
> > > What I might considers is a kind of automatic conversion to an arbitrary
> > > container.
> > > Something like
> > >
> > > string str=range.copy();
> > >
> > > "Copy" would return a stub object which will have implicit conversion to
> > > an arbitraty type.
> > > ( using enable_if, it can restricted to containers only )
> > 
> > IMO, not a good idea. I think all these twist/hacks that must be made to the
> > iterator_range<> says that
> > it's not specialized enough. We need a substring.
> 
> 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.

I think this reveals a fundamental issue with this library.  It
is called a "string" algorithms library, and that means something
like std::string, MFC's CString, etc. to most people.  This
library follows the STL convention of treating many things
alike.  (If it looks like a duck, and quacks like a duck, we call
it a duck.)  Thus, this library generalizes the notion of a
"string" beyond what many find comfortable or typical.
Recognizing this, the documentation must clearly, loudly, and
early set straight the record.

On the conversion issue raised above, may I point out that if the
underlying "string" container is std::basic_string in some form,
then conversions of iterator_ranges to the same string type
should be trivial, if not implicit.  Thus, if someone uses the
"string" algorithms library on std::string, then they should be
able to work with and convert to std::string very easily, with a
minimum of fuss.  Extra steps, especially steps that don't read
right, should be avoided.  Thus, the suggested copy() mf should
at least be named "str" in keeping with the STL, if the
conversion to the string type can't safely be made implicitly.

OTOH, if the "string" type is std::vector<char>, then conversions
to std::string should require extra glue logic, just as one would
expect when given a std::vector<char> and wanting to create a
std::string from it.  This library shouldn't be expected to treat
std::string as a lowest common denominator type, especially given
that some string types may not convert "normally" to std::string
(conversion traits aside).

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