Re: [boost] Preview 3 of the Geometry Library

Subject: Re: [boost] Preview 3 of the Geometry Library
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2008-10-16 08:11:48

Barend Gehrels wrote:

> None of the algorithms use iterator pairs for polygons. Polygons might 
> have holes, in our library, so having just a sequence of points is not 
> sufficient to define a polygon.

I didn't say for polygons, I said for sequences of polygons (what used 
to be called multipolygons I think).
It's true however no algorithm take these at the moment, so let's 
consider sequences of points, aka linestrings.

> On the other hand, algorithms take linestrings by iterator pairs, which 
> was in fact a positive result of the discussions of this list.

It is good, but ranges would be more practical and less verbose.
Instead of passing two arguments (the begin iterator and the end 
iterator), you only pass one, a range (and by const-reference, not by 
value). A range is an object from which you can extract a begin and an 
end iterator (using boost::begin and boost::end). A std::pair of 
iterators is a valid range, but so is also any container.

Consider std::for_each, here how you make it range-aware:
template<typename Range, typename F>
F for_each(const Range& r, F f)
{
      return std::for_each(boost::begin(r), boost::end(r), f);
}

That way, you can directly pass a linestring, a vector of points, a 
deque of points, a lazily computed adaptor or whatever to the algorithms 
with concise syntax: ie. just 'foo' instead of 'foo.begin(), foo.end()'.

> Agree, where it makes sense. The "within" algorithm is not symmetric, a 
> point can be within a polygon but a polygon cannot be within a point.

If the case can never happen, why not make an overload that simply 
returns false?
If I have generic code and I want to know whether an instance of T1 is 
within an instance of T2, I don't really want to make special the case 
where T2 is a point before calling the generic algorithm.