Hi Mats,
On 28-7-2013 12:23, Mats Taraldsvik wrote:
Hi,
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