[boost] Re: Re: token_iterator comments, suggestions

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-06-06 07:41:48

"Pavol Droba" <droba_at_[hidden]> wrote in message news:20040606113559.GL19968_at_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