Re: [boost] range adaptors

Subject: Re: [boost] range adaptors
From: Neil Groves (neil_at_[hidden])
Date: 2010-12-28 17:32:34

On Tue, Dec 28, 2010 at 5:58 PM, barend <barend_at_[hidden]> wrote:

> hi,
>
> First of all I like the new range adaptors, thanks for creating them.
>
> As much of Boost.Geometry is range-based, we like to support them. So I
> recently created a small integration, enabling things as:
>
> int n = boost::geometry::num_points(my_line | filtered(not_two()));
>
> where it filters out the points having a coordinate with 2 (just for
> testing). It works great, and most the adaptors, like strided, sliced,
> uniqued, reversed, seem very useful to me in this context.
>
> To enable this use I needed to specialize one of our structures to match
> boost range adaptors, like this:
>
> template<typename Filter, typename Geometry>
> struct tag<boost::range_detail::filter_range<Filter, Geometry> >
> {
>     typedef typename geometry::tag<Geometry>::type type;
> };
>
> This was all that was necessary to enable range adaptors.
>
>
Excellent. I'm happy you have been able to add support as easily as
intended.

> I now discover that their names are recently changed, from filter_range to
> filtered_range, etc (to match the adaptors, understandable).
>
> Of course library developers may do these things in a namespace called
> range_detail, but I've some questions:
>
> - do you encourage or support or discourage using filtered_range etc. in
> library code? Namespace range_detail is normally not used by library users,
> but there is no other way for us to adapt them: the filtered function
> returns a range_detail::filtered_range struct, and we have to specialize on
> that specific struct...
>
>
The question you have asked is exactly why the change has been made. Your
use case was only possible to solve using range_detail. This is simply
unacceptable, so the range return types are now documented. There was a Trac
ticket raised with respect to the inconsistent naming of the range return
types, and since I am about to make them an official and documented part of
the interface it seemed sensible to change the names now.

> - if this is a generic need, would it not be better to move them out of
> namespace *detail?
>
>
Yes indeed. This has been done. They are often implemented in range_detail
and then pulled out with using.

> - I noticed that sliced and copied are not in namespace range_detail but in
> adaptors, for me that sounds OK, but it is expected that for consistancy it
> might move namespace in any future
>
>
For the trunk version, all of the range adaptor return types can be accessed
from the boost namespace. Not all of the return types are necessarily
implemented in the range_detail namespace, but this shouldn't be a concern
to the best of my knowledge and belief.

> - are there more changes on the way?
>
>
Yes, but not to naming, and not breaking backward compatibility. I am unsure
how much I can get into the 1.46 release, but I have been working on a
type-erasure range adaptor. I am testing a modification to improve
compatibility with C++0x being/end. I am hopeful that people aren't using
ADL to find the boost::begin / boost::end then this will break, since this
is expressly discouraged in the documentation.

> Regards, Barend
>

Thanks,
Neil Groves