Re: [boost] Re: String algorithm library

From: Pavol Droba (droba_at_[hidden])
Date: 2002-11-19 02:59:56

On Mon, Nov 18, 2002 at 06:52:53PM +0100, Gennaro Prota wrote:
> On Mon, 18 Nov 2002 09:25:38 +0100, Pavol Droba <droba_at_[hidden]>
> wrote:
> 
> >You are probably right that some ideas are confusing without explanation.
> 
> In fact the reason why I was perplexed is that everybody seems to
> focus on minor issues like the names of the templates, while the
> design should be addressed first IMHO. That's odd because people here
> are not likely to let errors easily pass.

Thanks for comments. I appreciate them very much. This is very first version of the
library and I'm willing to change it to more usable way. Actually I'm already working 
on some changes.
 
> [snip]
> >What I want to do in the future is to change default signature of trim to something
> >like you're proposing. There will be a variant with predicate and a set of standard
> >predicates. This way the locale stuff will be moved out to the predicate and will
> >not confuse you any more, I hope :)
> 
> Well, I'm confused by definition :-) Anyhow I think what you are
> proposing is actually an algorithm library. It provides
> *generalizations* of typical string algorithms. As I hinted at, trim()
> can be seen as an algorithm that removes the elements that satisfy a
> given predicate from the beginning of any sequence. 

You are right, I want to provide string algorithm
library, not just a bunch of functions to manipulate with strings.
Algorithms can be used anywhere they fit.

> Now, it's a matter
> of how much information you need and how you want to provide it. From
> the perspective of generic programming the choice I find natural is a
> pair of iterators and a predicate. To do the same job with "spaces"
> you need ctype<>, but that's easily solved with an appropriate
> functor:
> 
> 
> // WARNING: completely untested!!!
> //
> template <std::ctype_base::mask Type, class charT = char>
> class is_classified_as : public std::unary_function<charT, bool>
> {
>     std::ctype<charT> const & m_ctype;
> 
> public:
> 
>     // ctor from a ctype
>     is_classified_as (std::ctype<charT> & ct) : m_ctype(ct) {}
> 
>     // ctor from a locale (for convenience)
>     is_classified_as (std::locale const & loc = std::locale())
>         : m_ctype(std::use_facet< std::ctype<charT> >(loc)) {}
> 
>     bool operator() (charT c) const { return m_ctype.is(Type, c);} 
> 
> };

this one I haven't though of. Looks interesting
> 
> 
> What I would see is a bunch of trim variants accepting a predicate
> and, separately, a bunch of string-specific versions like e.g:
> 
> 
> template <typename StringT>
> StringT trim_left(StringT const & str,
>                   std::locale const & loc = std::locale())
> {
>     typename StringT::const_iterator it
>         = std::find_if(
>             str.begin(),
>             str.end(),
>             std::not1 (is_classified_as<std::ctype_base::space>())
>         );
>     
>    return StringT(it, str.end());
> }

> 
> 
> Don't stop too much on the details though, because that's just to
> explain the idea.

As for the functor stuff. Internaly the trim functions are implemented
exactly the way you are proposing. There is isspaceF functor which is
called by transformation function.
Anyway I'm currently changing interface to support user defined predicates.
Library will contain a set of default predicates and shortcuts to use them. 

Any ideas about what functors to include are welcome.

> 
> (BTW if there's interest in a collection of functors like the one
> above for integration with STL algorithms as well I'm willing to
> volunteer)
>

Regards,

Pavol