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 <
> Neil Groves wrote:
>> I'm unsure what the Boost::RangeEx::iterator would be, and why we need
>> 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(),
>> on our existing implementation of iterator_range. Currently it appears
>> the non-member functions already in Boost.RangeEx make the support for
>> the Boost.Range-esque ranges and the Alexandrescu-esque ranges possible,
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk