[boost] Re: Re: sub string and string algo.

From: Alexei Novakov (alexei_novakov_at_[hidden])
Date: 2002-11-25 11:57:25

"Pavol Droba" <droba_at_[hidden]> wrote in message
news:20021122235345.J5713_at_lenin.felcer.sk...
> On Fri, Nov 22, 2002 at 02:03:49PM -0500, Alexei Novakov wrote:
> >
> > > [snip]
> > >
> Well, in the current state, the string_algo library provides a generic set
of string
> related algorithm. There are many reasons I choose to support any sequence
not just the string.

Can you list these reasons? I have browsed string algorithm library
discussion and found only one you've mentioned:
<quote>
Well I have reasons to put it in the way I did. Rationale was to allow usage
of the
functions in fuctional way. I consider it quite natural to write something
like
if ( to_lower(trim(s)) == "OK" )
{
// do somethign with original s
}
There are many cases like this in which you probably don't want modify input
sequence.
</quote>
This is exactly why sub_string was introduced. If sub_string is returned
master string will not be modified and new string will not be allocated.

Are there other reasons?

>
> I understand quite well, that in most cases the lib will be used with
variants of a the string,
> however I don't like to sacrifice functionality in the favor of general
pattern when it is
> not needed.

It is good to have generic algorithms, but there is always danger to become
too generic. There is a pretty comprehensive set of generic algorithms to
work with generic containers in the Standard. It would be good to have
special algorithms for special cases, like string algorithms for string
manipulation. But here you are trying to provide special algorithms for
general cases, like string algorithms for generic containers.

> As you can see, library is not just about trim function for which the
usage of substring is very
> obvious. For most of others in the current implementation the usage of
substring is questionable.

Sure, utility classes should be used only where applicable.

> There are places however where we benefit from each other. For example
ther was proposal for
> functions like substr_until( const string& str, const string& substr )
which should give you
> the string from beginning until the first occurenc of the substr. This
looks like perfect
> contructor for your sub_subtring. Also find algorithms can be used for
sub_string construction
>
> If I thinking about joining, I have one idea. In the similar way you have
substring, if may be possible
> to define generic sub_sequence class which would adapt to a sequence
container. I think this
> could be quite handy and I assume that with a little bit of refactoring
you can make the
> sub_string class a specialization of this generic sub_sequence. Such a
class could be then easily
> integrated with string_algo.

For generic case like this I believe that pair of iterators would be pretty
good representation for generic sub sequesnce... However I need to think
more about it. Definaltely sub sequence will not have 80% of string
interface implemented, which will make it practically unusable in string
field for which string algorithms are targeted. I think this is an example
of going too generic.

> So what do you think aboout this?
>
> Pavol

I have uploaded sub string to
http://groups.yahoo.com/group/boost/files/sub_string.zip.

Reagrds.

Alexei.