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

From: Pavol Droba (droba_at_[hidden])
Date: 2002-11-22 17:53:45

On Fri, Nov 22, 2002 at 02:03:49PM -0500, Alexei Novakov wrote:
> 
> "Pavol Droba" <droba_at_[hidden]> wrote in message
> news:20021122085106.D5713_at_lenin.felcer.sk...
> > Hi,
> >
> > On Thu, Nov 21, 2002 at 02:48:09PM -0500, Alexei Novakov wrote:
> >
> > [snip]
> >
> >  > > Alexei.
> > > >
> > > > Cool, I'd definitely use it
> > > > Seeing as there is a move to submit a library of string helpers at the
> > > > moment it might be worth submitting this at the same time!
> > > >
> > > > Vin
> > > >
> > >
> > > I think that these two libs (sub_string and string_algo) could  benefit
> from
> > > each other. How do I share the code so that members could see it and try
> it?
> > >
> > > Alexei.
> > >
> >
> > I'm working on the string_algo library. It has a different orientation in
> some way,
> > but I think there are places in which these two libs can benefit from each
> other.
> >
> > There is the boost sandbox cvs and you can read about it from boost web
> page.
> > If you gain access to is, you can have a look into my string_algo lib.
> >
> > Then we can maybe try to find out where we could join our efforts.
> >
> > Regards,
> >
> > Pavol
> >
> 
> Oh yes, I did so some time ago and played with string_algo. It seams to me
> that more convenient and natural return type for kinds of trimmers and
> sub_string extractors would be dedicated sub_string class rather than pair
> of iterators. You are using a little bit different approach - your
> algorithms are sequence oriented rather than string oriented. On one hend
> string is a sequence of chars, but on the other there is a good reason why
> dedicated string class was introduced instead of vector<char>. Consider the
> code:
> 
> string str("   ***123   ");
> sub_string ss = trim(str); // ss == "***123", but no allocation is done yet.
> // work with ss as with basic_string.
> // We need to do another trim.
> ss = left_trim(ss, "*"); //  ss == "123", still no allocation.
> // Let's create real string now;
> string str1 = ss; // str1 == "123"
> 
> sub_string is not really usable without a good set of string oriented
> algorithms, as well as algorithms look pretty bulky without being backed up
> by good utility classes.
> 
> What do you think?

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.

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.

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.

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.

So what do you think aboout this?

Pavol