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
- 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk