"Pavol Droba" <droba@topmail.sk> wrote in message news:20040606113559.GL19968@lenin.felcer.sk... [snip] | > 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. yes, that is why I suggest we keep both. | The range<> you're proposing is only a syntactic sugar. It migh be good, but I'm not sure, | if it is worth it. I think it would be an improvement in this case. Remember that the main reason for range-based algorithms were "syntactic sugar". By having range arguments we avoid dealing with iterators until we have to or want to; the same should hold for the return values of such algorithms for the whole concept to be consistent. If the return value is iterator-based, we take a step back in abstraction level. | > 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. aah, is_any_of() is part of the string library, right? br Thorsten