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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-02-02 09:50:20

"Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message 
news:m1fz0ff8q8.fsf_at_tulip.office.meta...
| Thorsten Ottosen writes:
| > 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;
|
| Assuming that 'operator[]' is provided only for Random Access
| iterators, the above three are very reasonable.

yes, only when the underlying range has randomaccessiterators.

| > value_type& at( size_type ) const;
|
| Is it a checked version of 'operator[]'?

yes.

| > void advance( size_type );
| > void narrow( size_type left, size_type right );
| > iterator_range& operator++();
| > value_type& operator*() const;
|
| Please NO. 'narrow' can be a freestanding utility function,

front() and back() are also easy to make freestanding, but the
idea was that these two helper functions should be made just a little
more convenient.

So you don't think the iterator capabilities is worth the trouble?

| and the
| rest is at best a questionable "convenience" baggage with no value for
| generic code. Also, think "standardization".

Do you mean make_sub_range() and the others?

br

-Thorsten