Hi Mats,

On 28-7-2013 12:23, Mats Taraldsvik wrote:

On 07/26/2013 11:54 PM, Michael Winkelmann wrote:

It would be very useful to expand on the for_each algorithms. However, as I understand the boost.geometry documentation and your proposal, there is a subtle but important difference: the current for_each_point algorithm work on a point _concept_, while your for_each<point> algorithm work on a concrete point type (in this case bg::model::d2::point_xy<double>.

I don't see why this would not work for concepts?

What if I used e.g. std::pair to represent points? I'd have to remember the exact type used for points in the polygon/ring/linestring/segment... I might have two polygons that represents points in differents ways, and then I'd have to implement the algorithm twice (for_each<bgm::d2::point_xy<double>> and for_each<std::pair<double,double>>.

I'm not sure if this is solvable in the generic case until we get proper Concepts (lite), which, combined with generic lambdas would make a concepts-based interface.

OK now I see what you mean. The proposal has probably to be read as:

size_t a = num<ring_tag>(myPolygon); // Returns number of rings in polygon
size_t b = num<segment_tag>(myRing); // Returns number of segments in ring
size_t c = num<polygon_tag>(myPolygon); // Should return 1

The tag's are mostly used internally, if used externally, they could (maybe) be namespaced e.g.

size_t a = num<geometry_type::ring>(myPolygon); // Returns number of rings in polygon

(don't know if this name is appropriate, just an idea)

What do you mean by Concept (lite)?

Regards, Barend