Hi, On Sun, Jun 06, 2004 at 11:35:44AM +1000, Thorsten Ottosen wrote:
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote in message news:c9tphv$aib$1@sea.gmane.org... | "Pavol Droba" <droba@topmail.sk> 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.b... )
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.
I is clear that iterator_range must work on the iterator basis, because there is not one-to-one relation between containers and iterators. The range<> you're proposing is only a syntactic sugar. It migh be good, but I'm not sure, if it is worth it.
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?
You can already do the think like this. Simply write boost::token_iterator( !is_any_of(",; ") ); There are also operators && || that can be used to combine classification predicates. Regards, Pavol