Re: [boost] String algorithm library

From: Pavol Droba (droba_at_[hidden])
Date: 2002-11-16 10:46:45

On Fri, Nov 15, 2002 at 06:47:35PM +0100, Thorsten Ottosen wrote:
> >    Seq rtrim( const Seq& Input, const std::locale& Loc=std::locale() )
> >    Seq& rtrim_in( Seq& Input, const std::locale& Loc=std::locale() )
> >    Seq trim( const Seq& Input, const std::locale& Loc=std::locale() )
> >    Seq& trim_in( Seq& Input, const std::locale& Loc=std::locale() )
> 
> I would find it more naturally to say
> 
> string s = ...;
> trim( s );
> 
> than to use 'trim_in()'. I think the functions that return a new 'Seq'
> should be the special cases, perhaps
> just with an appended underscore? Or maybe we should rely on that there is
> only one version of trim etc.
> and we would do
> 
> string s2 = s;
> trim( s2 )
> 
> instead of
> 
> string s2 = trim( s );
> 
> ? I guess could be considered for the rest of the library and I think It
> would simplify usage too, since it
> destinguishes between queries and commands. The prototype would then just be
> 
> void trim( Seq& input, ... );
> 

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.
So in the functional approach when you usualy stack multiple transformation in one line
especialy in conditions. When expression gets complicated it could be quite anoying and 
less readable to use variants with suffix of prefix.

While using the functions for in-place transformations is usually done in the separate line
and if the function has some suffix, it ususaly does not matter because expression is
separated.

The expample above partly explains also the reason why in-place variants return reference
to the container. This way it is easier to write

to_lower_in( trim_in( do_some_other_transform( s ) ) )

maybe the suffix _in is not the best, and i'm open to any suggestions, but I like you to 
consider my reasons to keep non-modifying variants as default.

> > Predicates:
> >
> >    bool start_with(
> > InputIterator Begin,  InputIterator End,
> >       SubIterator SubBegin, SubIterator SubEnd,
> >       BinaryPredicate Comp )
> > bool start_with( const Seq1& Input, const Seq2& Prefix, BinaryPredicate
> Comp )
> > bool end_with( const Seq1& Input, const Seq2& Prefix, BinaryPredicate
> Comp )
> > bool contains( const Seq1& Input, const Seq2& Prefix, BinaryPredicate
> Comp )
> 
> I think the names should be 'starts_with' and 'ends_with', right?
> 
Thats a good point. I can easily fix this

> BTW, much of the argument passing resembles what will be possible in the new
> container algorithms I'm working on.
> I guess you might just forward 'Seq.begin()' and 'Seq.end()'. In the
> container
> algorithms it will be possible to say
> 
> int                            a[] = ...;
> pair<iterator,iterator> p = <two iterators denoting a range>
> vector<int>                v = ...;
> 
> for_each( array, print()  );
> for_each( p, print() );
> for_each( v, print() );
> 
> What is relevant here is that the code below does not call .begin()/.end(),
> but overloaded
> freestanding begin() / end() functions. If your code should work with char
> arrays or iterator ranges,
> then you could benefit from the container algo. begin/end functions
> approach. However, there is a big problem, namely that
> the container algorithms don't work on eg. VC6/7.

This sounds interesting. I have seen your library in the sandbox, and I've even
written a mail to Jeremy who I thought is a co-author of the lib.

I'm open to any ideas, but I consider compatibility with compiler like VC6/7 
as an important issue. But I coudl be possible to #ifdef sensitible code and
keep at least the core of the lib to be usable for everyone.

It would be nice If you can provide me with more details about your work.

Pavol