Re: [boost] [boost.range] RFC on small updates

From: Pavol Droba (droba_at_[hidden])
Date: 2005-02-01 18:05:53

Hi Thorsten,

On Tue, Feb 01, 2005 at 11:07:56PM +0100, Thorsten Ottosen wrote:
> Hi All,
> 
> I have planned to add a few extra convenience function to
> iterator_range and sub_range. Some people have said the classes
> could have been a little easier to use. The changes I suggest are the 
> following:
> 
> iterator_range:
> --------------
> 
> value_type& front() const;
> value_type& back() const;
> value_type& operator[]( size_type ) const;
> value_type& at( size_type ) const;
> 

These functions seems usefull. However, I think, that operator[] should
be available only when underlaying iterator is random-access like

> void advance( size_type );
> void narrow( size_type left, size_type right );
> iterator_range& operator++();
> value_type& operator*() const;
> 

I assume, that these are inspired by John Torjo's RTL. I'm not very keen of them,
since I consider the using of an iterator_range instead of iterator confusing.

But it is only my personal opinion. I would rather include this functionality 
elsewhere (iterator lib?)

> sub_range:
> ----------
> 
> the same, but now constness is propagated
> 
> freestanding:
> ------------
> 
> iterator_range make_sub_range( range&, size_type left, size_type right = 0 );
> iterator_range make_super_range( range&, size_type left, size_type right = 
> 0 );
> iterator_range make_range( range&, difference_type left, difference_type right 
> = 0 );
> 

Generaly the same issue as above applies. However, I find these functions
not so offending. There might be a use for the them (last one especialy).

What I find important when including such a functions is to make sure, 
you don't get into the problems with less capable iterators.
(i.e that you don't disable the iterator_range for forward-only iterators
 for instance)

Regards,

Pavol.