Boost logo

Boost :

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.

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.
[+63 928 7291459]
[+1 408 4049523]

Boost list run by bdawes at, gregod at, cpdaniel at, john at