[boost] Re: token_iterator comments, suggestions

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-06-05 20:35:44

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> wrote in message news:c9tphv$aib$1_at_sea.gmane.org...
| "Pavol Droba" <droba_at_[hidden]> wrote in message

[snip]

| 1. Your library is dedicated to string algorithms.

[snip]

|    Iterator range does may be usable, BUT outside of string algo library.

(We have agreed to move iterator_range to Boost.Range.)

This is a discussion we need to have at some point. Either now or as part of
the post-review of the string algorithms.

Consider for example one of Pavols algorithms in the string library:
(see http://lenin.felcer.sk/~droba/boost-book/string_algo.reference.html#header.boost.string_algo.find.hpp )

template<typename InputContainerT, typename SearchContainerT>
inline iterator_range< typename result_iterator_of< InputContainerT >::type >
find_first(InputContainerT &, const SearchContainerT &);

compared to what I tend to like better

template<typename InputContainerT, typename SearchContainerT>
inline range< InputContainerT >
find_first(InputContainerT &, const SearchContainerT &);

I think that is a drastic reduction in interface complexity. In the former, the algorithm is range based yet the
return value have been specified with iterators.

My current view is that Boost.Range should contain both itarator_range<> and range<>,
but that range-based algorithms should use range<>

| There are couple of things that your solution provide in addition to what my
| and boost::tokenizer solution provide. Particularly it's an ability to
| specify several addition delimitation policies. I thought about this.  But
| it isn't on top of my priorities (mostly because it is comparatively rarely
| needed).

one token separator policy that could be usefull is the everything_but_one_of( ",; " );
but maybe we're starting to overlap with regex_token_iterator here?

br