Hi Eric! On Nov 19, 2007 12:17 PM, Eric Niebler <eric@boost-consulting.com> wrote:
Dean Michael Berris wrote:
Thank you very much! This definitely looks like something worth looking at. Is there any chance this work can get completed soon? Or is there just too many STL algorithms to 're-implement'?
Oh it's "complete", as in all the STL algorithms are represented.
Ah. The documentation "TODO's" are there to throw me off... Thank for the links! Will this get into Boost through the Boost.Range library, or will it go through a different review?
I'm quite possibly looking at helping here if there's anybody else needing help with the implementation of this library.
There are some surprisingly thorny issues wrt range-based algorithms, which I list in the appendix of the range_ex docs. In particular, does an "output range" make sense? Range_ex uses output iterators instead of output ranges. At the time, I thought that was unsatisfactory. Less so now, but it's still an open issue.
When I look at the SGI extensions to the STL, there are versions of std::transform that take in a couple of ranges: one an input iterator range, and another an output iterator range. These make sense if you're putting the results of a function application f(x) into a predefined range usually associated with a non-const container. Example: std::transform( input_range(my_vector), output_range(other_vector), f() ); The preconditions are that output_range's size and input_range's size are the same. This can also be extended to the concept of an infinite range, in cases of the ostream_iterator: std::transform( input_range(my_vector), ostream_range(std::cout), f() ); For the precise case also for when you want the transformation 'f(x)' are applied to the same input range: std::transform( input_range(my_vector), output_range(my_vector), f() ); I hope this makes a case for output ranges -- but then they can be precisely overloads of std::transform, which they precisely are.
* SGI's select1st and select2nd generalized -- I'm not sure if you've found yourself dealing with std::map's and std::list<std::pair<,> >'s a lot, but I do, and there is a lot of merit in something like the following:
template <const N> struct select { template <class T> mpl::at_c<T, N>::type operator() (T element) const { return mpl::at_c<T, N>(element); }; }; <snip>
Could this simple header library be put into the Fast Track review queue?
I think I would make this part of boost/functional.hpp, but I'm not sure who is maintaining that these days.
That makes sense as well. I'll try starting another thread for this one. -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mikhailberis@gmail.com] [+63 928 7291459] [+1 408 4049523]