Re: [boost] Preview 3 of the Geometry Library

Subject: Re: [boost] Preview 3 of the Geometry Library
From: Barend Gehrels (barend_at_[hidden])
Date: 2008-10-16 10:49:27

Mathias,
>
>> 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()'.
I agree, it is shorter and more elegant, we'll consider adding / 
replacing by range support, it'll probably not largely influence the 
structure of the library. Indeed Phil, who indicated the use of 
iterators on this list, already mentioned the ranges.

>
>> 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.
>
Also here I agree.

Besides this, in the past discussions concerning the previous previews, 
and the other submissions, discussions concentrated on the points. How 
it was modelled and how it should look like. Until now I didn't saw any 
comments on this (besides construction of generic geometry objects). Can 
we conclude that the list is now satisfied with the provided point concept?

Barend