Subject: Re: [geometry] generic for_each and num proposal
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-07-28 13:59:51
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