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