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