Re: [boost] AlRangeExandrescu?

Subject: Re: [boost] AlRangeExandrescu?
From: David Abrahams (dave_at_[hidden])
Date: 2009-07-28 18:23:30

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