On Tue, Jul 28, 2009 at 9:25 PM, Andrei Alexandrescu < andrei@metalanguage.com> 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