Re: [boost] AlRangeExandrescu?

Subject: Re: [boost] AlRangeExandrescu?
From: Neil Groves (neil_at_[hidden])
Date: 2009-07-28 16:57:01

On Tue, Jul 28, 2009 at 9:25 PM, Andrei Alexandrescu <
andrei_at_[hidden]> wrote:

> Neil Groves wrote:
>
>> I'm unsure what the Boost::RangeEx::iterator would be, and why we need
>> such
>> a thing.
>>
>
> Without having perused either Boost::Range or Boost::RangeEx, I think it's
> customary to give named access to the underlying iterator type, just like
> containers e.g. define iterator, size_type etc.
>

Oh I see, we have something that achieves a similar goal, I think. We have
the iterator type in a typedef within the range classes currently. The
prefered manner to write a range algorithm though uses a type generator
class: range_iterator< Rng >::type to allow access to the underlying
iterator type. This allows extension and support for ranges non-intrusively
so we have been able to add range algorithm support seamlessly to even MFC
containers, for example. Does this appear optimal to you, or can we improve
this arrangement? I have to confess I'm still studying the proposals to have
different iterator types for begin and end, and I have yet to fully
understand the impact. Hence I will apologise in advance for my ignorance.

>
>  Since we have non-member functions for boost::begin(end),
>> boost::end(rng) we can have ranges that model the newer concepts not
>> implement the begin(), end() ,member functions.
>>
>
> Oh, I see (s/(end)/(rng)/ I guess). That makes sense.
>
>  It seems that the
>> pop_front(), pop_back(), operator[] map onto advance_begin(),
>> advance_end()
>> on our existing implementation of iterator_range. Currently it appears
>> that
>> the non-member functions already in Boost.RangeEx make the support for
>> both
>> the Boost.Range-esque ranges and the Alexandrescu-esque ranges possible,
>> if
>> not necessarily simple.
>>
>
> Perfect. But for ranges to catch up, I guess an easier to spell name would
> be in order...
>

You are completely correct. I will probably be plagurising your work for
these, if that is acceptable.

>
>
>
> Andrei
>

Regards,
Neil Groves