Subject: Re: [geometry] generic for_each and num proposal
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-07-29 17:46:36
Hi Mats,
On 29-7-2013 19:41, Mats Taraldsvik wrote:
> Hi Barend,
>
> On 07/28/2013 07:59 PM, Barend Gehrels wrote:
>> 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)
>
> I'm sorry, I could have been more clear (and I might simply be wrong
> :) ). I think the num-part of the proposal is fine with *_tag as
> template arguments. As long as the actual algorithm is written with
> the operations required by the point concept, it should work for every
> type that satisfies the point concept. And it is very useful indeed! :)
>
> Sorry if I come across as negative with my (hopefully constructive)
> criticism, I'm trying not to be. :)
No problem, no worries, thanks for your reaction - it certainly helped
to make things clear. So it was constructive :-)
Thanks for your new mail too.
>
> What I'm concerned with is the lambda argument to the for_each<*_tag>
> algorithms. I'm not aware of a way to write a lamdba in terms of a
> (geometry) concept, so they will be type-specific instead of
> concept-specific. Which means they have to be tailored to the type of
> the point/linestring/polygon etc. -- not the concept (which is ideal).
>
> Consider a Polygon that has four points of different types:
>
> bgm::d2::point_xy<double> point1
> std::pair<double, double> point2
> bgm::d2::point_xy<double> point3
> std::pair<double, double> point4
>
> How do you write the for_each<point_tag> where the lambda is able to
> capture all four points? One could use a boost::variant or similar
> structure to account for all point types, but it isn't ideal, is it?
> (However, this might be the best solution for current C++(?))
Good point. Lambda's are written in a context, so the program or
function or class-method or whatever. So if you have a main program, you
use the point-type you define. Because the lambda is programmed and used
only once you specify the type you need. These lambda's are never reused
for other type. If you are in a template function or class, you can
simply use the template-argument (which can be of any point-type, as
long as it follows the context). So it all follows normal rules, only
the lambda-function itself is not templated but does not need to be.
This all is not really related to Boost.Geometry and also applies for
std::for_each.
So it is possible; variants are not necessary.
I attached two programs (based on something I already had) to show these
both uses. So it (the template version) works for any Concept. In the
non-template version, it is simply not relevant to tailor it for many
types (and not possible indeed).
>
> Also, what if we decided to have some pre-defined lambdas/functions
> that one could use with for_each<*_tag>? They'd have to be generic
> (i.e. concepts-based) to be truly useful and universally applicable...
>
>> What do you mean by Concept (lite)?
>
> Concept[s] lite is the current proposal for constraining templates,
> and, by extension, generic lambdas (c++14). It is planned as a TS in
> the C++14 timeframe, as far as I know. The latest version is N3701,
> look at the summer standards papers mailing [1] -- I think it is
> really interesting, I think it is worth a look if you are not familiar
> with it already.
I was not aware of the "lite" addition. OK, so this looks like the
Concepts, postponed in C++11.
Boost.Geometry uses concepts and checks it by Boost Concept Check
Library (BCCL).
>
> I think this would allow the behaviour I am seeking:
>
> for_each<point_tag>( aPolygon, [](PointConcept point)
> {
> ...
> });
Here, you can make use of the type of the aPolygon parameter (either a
concrete type or a template), and then use (as soon as for_each is
tagged, for now: for_each_point):
boost::geometry::for_each<point_tag>
(
aPolygon,
[](boost::geometry::point_type<polygon>::type const& p)
{
...
}
);
>
> or, a pre-defined function
>
> auto point_to_wgs84(PointConcept point)
> {
> ...
> }
>
> ...
>
> for_each<point_tag>(anotherPolygon, point_to_wgs84);
This is also already possible (with for_each_point, without point_tag).
You have to specify the template argument explicitly in the call (and
note you are missing template <typename PointConcept> in your function
definition). But that is no problem - it might even be a
template/concept (like with lambdas). This variant is listed in the help:
http://www.boost.org/doc/libs/1_54_0/libs/geometry/doc/html/geometry/reference/algorithms/for_each/for_each_point.html
(list_coordinates)
Regards, Barend