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. :)
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++(?))
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 think this would allow the behaviour I am seeking:
for_each<point_tag>( aPolygon, [](PointConcept point)
{
...
});
or, a pre-defined function
auto point_to_wgs84(PointConcept point)
{
...
}
...
for_each<point_tag>(anotherPolygon, point_to_wgs84);
Where PointConcept is the boost geometry point concept. Thus, the
actual points in the polygon could be of different types, as long as
the point concept is satisfied, the lambda should work for all of
them.
Regards, Barend
[1]
http://isocpp.org/blog/2013/07/summer-standards-papers-mailing-available
It's a future direction, I guess, but I thought it might be worth
pointing towards. :)
Mats
_______________________________________________
Geometry mailing list
Geometry@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/geometry