Re: [boost] Formal Review: Boost.RangeEx - missing algorithms

Subject: Re: [boost] Formal Review: Boost.RangeEx - missing algorithms
From: Neil Groves (neil_at_[hidden])
Date: 2009-02-22 09:11:30

Dear Vicente,

On Sun, Feb 22, 2009 at 12:13 PM, vicente.botet <vicente.botet_at_[hidden]>wrote:
<snip>
</snip>

>
> May be it will be godd to add the equivalences. The user can always include
> them in their application if they found useful.
>

I'm not sure about this issue. I really want to obtain feedback from as many
people as possible. I understand the appeal of providing everything that is
in <algorithm> but I dislike setting what is, in essence, a bad example of
how to write algorithms. My personal preference is to drop the inferior
technique, this will hopefully make it easy to do the right thing, and hard
to do the wrong thing. I am, of course, open to feedback on this issue.
Ultimately the library is for it's users.

>
> > The _n operations are replaced if the input is a model of the
> > RandomAccessRangeConcept with boost::copy( output, input | sliced(0, n) )
> > for example, but on reflection this can and must be improved before
> release.
> > If I simply add a first_n adaptor then we can replace all _n algorithms
> with
> > a superior adaptor for all valid ranges. Hence I propose to add something
> > that would allow:
> > boost::copy( output, input | first_n(n) );
> >
> > I am pleased that you made me justify dropping the _n versions, because
> > frankly my solution is currently insufficient to be a perfect substition.
>
> Yes, somthing like that should work, but what will be the difference
> between
> first_n(n) and sliced(0, n)?

The key difference is that while sliced works perfectly fine for
RandomAccessRange's it does not work for SinglePassRange's. It is possible
to make a first_n work for all valid Ranges. Hence I can't correctly state
that I have currently provided the tools to make the _n versions of the
algorithms always replacable with a superior alternative. I shall, because I
want to get rid of them, I should have provided a better alternative first.

>
>
> > As for is_sorted and is_heap, these seem like useful additions to the
> > algorithm_ext.hpp.
> >
> > And horror of horrors, the random_sample is missing due to no good
> > justifiable reason what-so-ever. This I will address.
>
> waiting for them.
>
> >>
> >> There are surely hidden reasons to don't include some of them.
> >>
> <snip>
>
> > I definately like the idea of carefully adding partitioning that is
> > compatible with Boost.Range. I need to revist posts and suggestions made
> by
> > others on this list.
> > IIRC Dr. Arnold Schodl had some interesting ideas, and partitioning is
> > actively being worked on.
> >
> >> But a dynamic one would also be interesting. What do you think?
> >>
> >
> > The only comment I can make at this point is that it requires some
> > investigation. There are others that have investigate partitioning in
> much
> > more detail and I it would be silly for me to comment before studying
> their
> > contributions. It appears to be something that can be extended and made
> > compatible with range very easily without affecting the core. Hopefully I
> > can still find enough time to make this happen before release.
>
> Could you give me some pointers?
>
> I have just a last question, is there any difference between
> using directly a Range
>    Range range;
>
> using a sub_range
>    boost::sub_range<Range> sub_rng(boost::begin(range), boost::end(range));
>

> and using a sliced adaptor
>    range | sliced(0, boost:size(range))
> ?
>

The idea is that the algorithm may be written without regard for what actual
range is being used. There are reasons to have iterator_range, sub_range and
special returns from the adaptors. I believe these are all documented, so
I'm going to be cheeky and ask that you look in the documentation for
sub_range. Indeed it is a core design goal that the user may provide free
functions to allow other containers to work with the range library
seamlessly. This indeed is exemplified by the code that allows ATL and MFC
'collections' to operate as ranges without requiring modification. The
relevant documentation is here index.html -> reference -> extending the
library.

The use of anything that is a valid model of the appropriate Range Concept
must work. It's a defect if it doesn't.

> Thanks,
> Vicente

Best Wishes,
Neil Groves

>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>