Re: [boost] Re: token_iterator comments, suggestions

From: Pavol Droba (droba_at_[hidden])
Date: 2004-06-06 06:36:00

Hi,

On Sun, Jun 06, 2004 at 11:35:44AM +1000, Thorsten Ottosen wrote:
> "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.

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