On Tue, Dec 28, 2010 at 5:58 PM, barend <barend@geodan.nl> 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