Re: [boost] string_algo review part 2

From: John Maddock (john_at_[hidden])
Date: 2003-10-24 07:06:57

> > 12) OK, I'm beginning to see the consistency in the *2.hpp headers now,
but
> > maybe if that's the intent, and you do want to keep them, then why not
call
> > them *_predicates.hpp, so we know what's what?  Just a thought.
>
> *2.hpp headers contain generic variants of algorithms. There is a section
about
> the layered structure of the library in docs. *2.hpp represents the second
layer.
> (a.k.a string_algo namespace )

OK I found a section in the rationale (not the first place I would have
looked), it's hampered again by the docs for the individual functions not
indicating what namespace they're in.  My main point is that the naming
convension doesn't give the user any kind of a hint as to what's in what
header.

> And as I said I would prefer iterator based variants of split. But I have
one problem
> with it.
> I have implemented a "find_iterator". This class (you can have a look in
string_algo/detail/find_iterator.hpp)
> takes a Finder as an argument and then in each increment, use it to search
for the next match.
> Problem is that the signature of this class is rather complicated. It has
3 template
> parameters, most of them templated again. So it is hard to define an
variable with the required
> type to hold the iterator (auto-type variable would be a miracle here).
> I was thinking about making a type-generator template, but it would not
safe too much trouble,
> because you would have to specify all parameters anyway, only on a
different place.
>
> I haven't solved this problem so I rather droped this kind of interface
for the split algorithms.

How about:

template <class Container>
struct string_find_iterator
{
  typedef iterator_range<typename Container::const_iterator> value_type; //
etc

  string_find_iterator(); // end of sequence
  template <class Predicate>
  string_find_iterator(const Container& c, const Predicate& pred); // what
to find

  const value_type& operator*()const;
  // other members etc
};

Notice that you only have the one template parameter (the container type),
the template constructor takes a predicate indicating what to match, and
gets "virtuallised away" internally: the operator++ would have to make a
virtual function call, but that's likely to be an irrelavent cost compared
to the cost of a string find.

Just off the top of my head... :-)

> > 14) trim2 and trim.hpp don't have the relationship I suspected in #12
:-(
> >
> See 12.

Not quite, my point was that you are using the "2" suffix for two different
kinds of headers - some kind of meaningful and descriptive suffix would be
better IMO - I'm not entirely sure that the second level namespace is really
needed either?

Regards,

John.