Boost logo

Boost :

Subject: [boost] range adaptors
From: barend (barend_at_[hidden])
Date: 2010-12-28 12:58:32


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.

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...

- if this is a generic need, would it not be better to move them out of
namespace *detail?

- 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

- are there more changes on the way?

Regards, Barend

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