Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-10-26 10:07:47


"Pavol Droba" <droba_at_[hidden]> wrote in message
news:20031026141956.GD17011_at_lenin.felcer.sk...

> > > > Consider algorithms with 'nth', eg.:
> > > >
> > > > ierase_nth_copy( s, "s", 1 );
> > > >
> > > > this does not erase the 1st copy of "s", but the second. What's the
> > > > rationale for this? I don't find it intuitive.
> > >
> > > The index is starts from zero. It is explicitly specified in the docs.
> > > Rationale for it is taht all c-array start with 0 and for cycles it is
> > > usual practice to go from 0.
> >
> > where in the docs? The detailed explanation says:
> >
> > "Search for an n-th match of search sequence in the input sequence."
> >
> > which means when I specify 0, I search for the 0-th occurrence of
something.
> > When we talk about arrays and containers it is understood by everyone
that 0
> > is the first index. When people talk about words/strings, it does not
make
> > sense anymore; there is no 0th index; there's the first occurence and
the
> > second etc. My point that it is two very different concept and practice
in
> > one cannot be used to dictate practice in the other.
> >
>
> 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.

> > > It is not a problem the add this to 1-layer interface. Question would
be,
> > > what would
> > > you await from replace_all_if?
> >
> > I would simply expect that I use a predicate to identify a match.
> >
> I'm asking, because replace by design works with substrings, rather then
with
> single elements (sure, one element is also a substring of a kind).
>
> replace_if would primary search for a single values, so I'm asking if
> ther replacement should be a string of a value?

yeah, I see now :-). Sorry, I guess there no easy answer to that question.

> > > Problem is when your string is not long enough. So would need to check
> > > all boundary conditions. _head does it for you. Because this operation
> > > is quite common, it is included int he library.
> >
> > 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.

> >
> > > > The iterator_range class. Maybe it should be called sub_string to
put
> > > > the
> > > > focus more on string algorithms instead of generic algortihms. The
> > > > border
> > > > between string and non-string algorithms seems to be fuzzy. Implicit
> > > > conversion to basic_string<T> ??
> > >
> > > Whole library is designed in the way that it is not restricted to
> > > std::basic_string.
> > > Therefor such a convention would break the rule.
> > >
> > chances are that basic_string will be used the most. Anyway, no matter
what
> > string you use, it would be nice if one did not have to covert
explicitly,
> > eg:
> >
> > string substring = find_XX( s, YY );
> > cout << find_XX( s, YY );
> >
> > instead of
> >
> > iterator_range< string::iterator> temp = find_XX( s, YY );
> > string substring( temp.begin(), temp.end() );
> > cout << string( temp.begin(), temp.end() );
> >
>
> what about
>
> string substring=copy_range<string>( find_XX( s, YY ) );
> cout << copy_range<string>( find_XX( s, YY ) );

it's better :-) ... but not optimal IMO.

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

> For streams, I can provide << >> operators. This seems reasonable.

sure do; then one can avoid the conversion.

> > > > Locales. Is there any reason why a locale need to be a parameter to
each
> > > > function? If one want's to use a specific locale in one function
call,
> > > > it
> > > > seems likely that the same locale would be used throught the entire
> > > > program.
> > > > I'm just wondering if it wouldn't be sufficient with some kind of
> > > > set_locale
> > > > function which then affected all the algortihms?
> > >
> > > If your program uses just one locales at the time, you are perfectly
ok
> > > with
> > > default values and you can use std::locale::global to set your
prefered
> > > locale
> > > settings.
> > >
> > > However there are applications when there is a need to used more
locales
> > > simultaneosly.
> > >
> > do you mean in two different threads? Otherwise I don't get it.
>
> 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.

cheers

Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk