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

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-26 10:50:20

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

[snip]
 
> > 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.
>

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

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.

[snip]

> > > ok, I did not see that. Maybe that could be explained in the docs?
> >
> > It is explicitly state what is a head :
> > "
> > Get the head of the input. Head is a prefix of a seqence of given size. If
> > the sequence
> > is shorter then required, whole sequence if considered to be the head.
> > "
> 
> Sorry, you misunderstood. I thought it might be a note ot FAQ item which
> said why one should
> not use the make_range example that I made and which lead to undefined
> behavior.

I don't think, that it is realy needed. User should realy be aware,
that he should not access the elements outside of the range ....
This is not related to the library.
 

[snip]
 
> > > 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.

[snip]

> > Imagine an MDI text editor, which allows you to edit text in different
> > languages.
> > Obviosly for every opend document, you need a different locales.
> 
> so you switch locale when you switch document; that doesn't mean that you
> need to specify a locale
> for each function invocation. My point is that is seems like a locale has a
> "global settings" nature.
> If it was a member of an object, then you would set it once and use all the
> algorithms until you needed the algorithms to work
> with a new locale.
> 

The convention in the library is 100% compatible with the C++ locales design.
I see no reason to break it.

And for the explanation:

Algorithms are global objects with no state. If only global locales would be
used, then in text editor example, every operation on a open document
would have to start with setting the locales and at the end, restoring them to
the previos state.
Such an opration is ineffective and against modern design conventions.

And btw, you are right the in multi-threaded multi-locales environment,
global locales are absolutely unusable ...

Regards,

Pavol