Boost logo

Geometry :

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
size_t b = num<segment*_tag*>(myRing); // Returns number of segments in
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

Geometry list run by mateusz at