on Tue Jul 28 2009, Neil Groves <neil-AT-grovescomputing.com> wrote:
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?
That's basic state-of-the-art for C++03 generic libraries, so I doubt there's much room for improvement within the current language. Well, you could use the concept check library to define the associated types within the concept classes; that's a slightly more forward-looking approach. -- Dave Abrahams BoostPro Computing http://www.boostpro.com