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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-02-03 14:53:45

"Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message 
news:m1lla6dm6b.fsf_at_tulip.office.meta...
| Thorsten Ottosen writes:

| > | > 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,

| > but the idea was that these two helper functions should be made just
| > a little more convenient.
|
| I understand that, but then consider that there are may be ten more
| such convenience functions lurking out there. We certainly don't want
| 'iterator_range' to become another 'std::string', do we?

well, no, but std::string is extreame.

| > So you don't think the iterator capabilities is worth the trouble?
|
| They are just one possible workaround for the lack of 'foreach',
| hardly commonplace and arguably unidiomatic, and as such are at best
| of a subjective utility. Something like that might be offered by some
| other library that targets to compensate this language shortcoming,
| but they certainly don't belong to 'iterator_range'. Straightforward
| and uncontroversial is IMO what we should target for here.
|
| >
| > | 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?
|
| I meant iteration shortcuts (advance, ++ and *).

in some sence operator*() is provided by operator[]()... I guess
random access iterators will fit must use cases like strings. But OTOH,
I don't see how two functions (let's scrap advance) can hurt at all, not even 
in
a standardization context.

-Thorsten