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
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
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)?