From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-02-02 09:50:20
"Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message
| 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'?
| > 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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk