on Tue Jul 28 2009, Andrei Alexandrescu <andrei-AT-metalanguage.com> wrote:
Mathias Gaunard wrote:
Andrei Alexandrescu wrote:
Now here comes an interesting possibility. Boost::RangeEx also defines a typename Boost::RangeEx::iterator, and begin() and end() that return iterators. But it makes them optional! Meaning, as much as there are forward vs. bidirectional ranges, there are ranges that cloak iterators versus ranges that don't.
Would there be any reason for a range not to provide iterators except those iterators being hard to write?
In case there is none, I don't think it's such a good idea to use concept refining for a non conceptual difference, but rather an implementation difficulty.
I'm very sympathetic to that point of view.
It's not only implementation difficulty. I have many ranges that make next no sense as iterators. For example I have a range that spits out random numbers. The notion is very easy to fathom as a range, but forcing it into the iterator framework would be forced for the designer as well as the user of the notion. The design would be a net loss for everybody if it were required to define an iterator.
Despite your first sentence above, it sounds exactly like you're saying it's just an implementation difficulty. Generator iterators are well-known, just like istream and ostream "iterators," and we have libraries that can help with implementation. However, not using refinement doesn't imply forcing ranges into the iterator framework Thinking in terms of (deferred) C++0x concepts, I'd write the Range concept that has no iterators, then write the IteratorRange concept that has iterators, then I'd provide a concept_map template that maps Range onto IteratorRange by providing default implementations. -- Dave Abrahams BoostPro Computing http://www.boostpro.com