Subject: Re: [geometry] generic for_each and num proposal
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-07-28 13:54:05
Hi Michael,
On 26-7-2013 23:54, Michael Winkelmann wrote:
> Hi all,
>
> I've played around a lot with boost::geometry and find the
> for_each_point and for_each_segment algorithm very useful.
> However, I think of a more generic approach which will makes most
> sense together with C++ lambdas:
>
> Let's assume we have a for_each template with the following type
> definitions:
>
> template<class SubGeometry, class Geometry, class Functor>
> for_each(Geometry& g, Functor f) { ... }
>
> typedef boost::geometry::model::d2::point_xy<double> point;
> typedef boost::geometry::model::polygon<point> polygon;
> typedef boost::geometry::model::ring<point> ring;
> typedef boost::geometry::model::segment<point> segment;
>
> E.g., if you have a polygon and want to iterate over each ring:
> polygon myPolygon(...);
> for_each<ring>(myPolygon,[&](const ring& r)
> {
> /* code here */
> });
>
> Or, if you want to iterate over each segment in a ring:
> ring myRing(...);
> for_each<segment>(myRing[&](const segment& s)
> {
> /* code here */
> });
>
> For the num_points algorithm, there might be an analogous generic
> definition:
>
> template<class SubGeometry, class Geometry>
> size_t num(const Geometry& _g) { ... }
>
> size_t a = num<ring>(myPolygon); // Returns number of rings in polygon
> size_t b = num<segment>(myRing); // Returns number of segments in ring
> size_t c = num<polygon>(myPolygon); // Should return 1
>
> I'd be glad to hear your opinions.
>
I like it!
Basically the for_each_point and for_each_segment should already work
with lambda's. So that is not the point here. But for_each<> instead of
for_each_{named thing} is definitely an improvement.
About num_points, yes, that is also good but... num_points and
num_interior_rings are prescribed by OGC (which we follow). If we leave
that (we could), then I would propose "size" instead, like STL does. The
num_interior_ring does have a tweak - you don't really know this... You
might say it is num<rings> - 1, but in case of multi-polygons that is
not valid.
For num<polygon>, this is 1 for a Polygon concept, but not for a
MultiPolygon concept.
Regards, Barend