I want to iterate over every point within a geometry::model::box<point>. I
want to be able to do that with iterators so that I can also use all (or
most of) the standard algorithms like for_each or all_of or etc.
Initially my code used several loops, one for each axis, like so for a 2d
point:
for (int x = box.min_corner().template get<0>(); x <=
box.max_corner().template get<0>(); ++x) {
for (int y = box.min_corner().template get<1>(); y <=
box.max_corner().template get<1>(); ++y) {
callback(point(x,y))
}
}
There are several places where this occurs. Some loops have the x axis
first, others the y axis first -- and this has performance issues when
translating the point to a container. Some loops were erroneously
considering right-open intervals with less-than instead of
less-than-or-equal-to comparisons. So I've had to fix bounding bugs and
performance issues in multiple places that are caused by these manual loops.
I've gone and unified a lot of that to use templated functions that
basically duplicate some of the functionality in the standard. But that's
not tractable and still doesn't use iterators so most of <algorithm> is
still off-limits:
namespace mynamespace {
template
void for_each(const box& b, const std::function callback) {
// the manual loops here, not repeated for brevity
}
}
Then I've replaced most of those manual loops with calls to:
mynamespace::for_each(box, [](const point& p){
// do some work here
});
So I want to instead do:
for (const auto& point : box) {
callback(point);
}
Satisfying that would make a lot of places simpler and easier to read. I
think it should also help to enable use of a lot of the stuff in the
standard <algorithm>
I understand that it might be difficult for, eg, a box containing a point
with floating point types. But that's fine ... I'm only looping over
integral points anyway.
I'd also prefer to have the ability to control the axis order ... eg do I
want x or y on the inner/outer loop? Do I want to only iterate over the y
axis?
I'm using C++14 and boost 1.70 at the moment. There's some friction against
upgrading. But if this problem is solved in a future version -- like with
C++20 ranges -- then that would be a strong point for me to convince my
team to upgrade.
I could go and write up some iterators myself of course. But before I do
that I wondered if someone else has already solved this problem and I just
haven't found the solution. Thoughts?
--
Keith Bennett
