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,
> > maybe if that's the intent, and you do want to keep them, then why not
> > them *_predicates.hpp, so we know what's what? Just a thought.
> *2.hpp headers contain generic variants of algorithms. There is a section
> the layered structure of the library in docs. *2.hpp represents the second
> (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
> And as I said I would prefer iterator based variants of split. But I have
> with it.
> I have implemented a "find_iterator". This class (you can have a look in
> 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
> 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
> I haven't solved this problem so I rather droped this kind of interface
for the split algorithms.
template <class Container>
typedef iterator_range<typename Container::const_iterator> value_type; //
string_find_iterator(); // end of sequence
template <class Predicate>
string_find_iterator(const Container& c, const Predicate& pred); // what
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk