Re: [boost] [range][algorithm] Looking for STL adaptations

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-11-20 00:11:40

Hi Eric!

On Nov 19, 2007 12:17 PM, Eric Niebler <eric_at_[hidden]> 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_at_[hidden]]
[[phone]]
[[phone]]