Hi Dave, On Thu, Jul 23, 2009 at 1:48 PM, David Abrahams <dave@boostpro.com> wrote:
Hi Neil,
I'm sure someone already spoke to you about this, but just in case: Andrei Alexandrescu gave a very interesting presentation at BoostCon that was based on a "ranges only" approach that should eliminate issues like this one:
2: return type specification for find() etc =========================================== There where no major objection to the mechanism, but some found the syntax ugly. I believe the suggested syntax (e.g.)
boost::find[_f,_e]( range, x )
boost::find[_f+1,_e]( range, x )
The current syntax that was proposed is not like this. In fact one need do no more than boost::find(range, x) for the default behaviour, but for obtaining a non-default range then something like boost::find<find_end>(range, x) is used. I don't find this very ugly and if one is going to allow a selection of differing return types then the choice needs to be made via a parameter somewhere whether one supports different Range concepts or not. I have briefly considered Alexandrescu's proposal, I am very excited to see a concrete proposal to make Range Concepts first class citizens, but on first glance they appear to introduce a coupling between traversal and access.Having a front() accessor member function as part of a Range Concept means that generic algorithms that are passed a range would need to know they were extracting from the front() or the back(). I haven't had time to think this through completely but it isn't clear to me at least that everything that is currently possible can be done with the suggested concepts. I'm also not sure how to fix the (imagined?) issue. Wouldn't a change of this magnitude require a fresh review? I'm not against doing this. In fact, if Andrei has already an implementation it may be best all around if his version is proposed instead. The current RangeEx is far more modest in it's aims, and perhaps this is simply not going far enough in the light of recent advances. I'd be happy to work with anyone that is interested in thrashing out superior Range Concepts. Also I think it only sensible to offer stepping down in the light of the very heavy weight names that now may be interested in taking this over if this would speed the progress along. I would very much prefer to continue and assist if at all possible without hindering things.
He says he's implemented a superset of the STL algorithms with it so we know the expressive power is fairly complete. I was wondering if you had given any thought to making use of his insights? Especially considering that RangeEx hasn't been used to fully cover a generic domain (I think), it might make sense.
I have used Boost.RangeEx not just to implement algorithms, but also to implement applications using the algorithms. I'm not really sure this counts for much however. Probably other people using the code would be far more valuable.
-- David Abrahams BoostPro Computing http://boostpro.com
Regards, Neil Groves