Re: [boost] Preview 3 of the Geometry Library

Subject: Re: [boost] Preview 3 of the Geometry Library
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-10-16 13:41:59

>> 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.
>
Mathias Gaunard wrote:
>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.

Here I disagree.  First of all, it is an absurd amount of work.  Fully
generic functions cannot be overloaded directly, so you would have to
use tag dispatching.

//legal input combinations:
// polygon polygon
// polygon rectangle
// polygon segment
// polygon point
// rectangle polygon
// rectangle rectangle
// rectangle segment
// rectangle point
// segment segment
// segment point
// interval interval
// interval coordinate
template <typename geo_type_1, typename geo_type_2>
bool within(const geo_type_1& geo1, const geo_type_2& geo2, bool
boundary_is_in = true) {
        return within(geo1, geometry_tag<geo_type_1>::type(),
                        geo2, geometry_tag<geo_type_2>::type(), 
                          boundary_is_in);
}

You can't specialize it either because that would mean rewriting the
entire library for every new type.  I want to emphasize that we are not
talking about making a boost::point and boost::polygon objects and
writing a bunch of functions that accept those types.  We are talking
about writing fully generic functions that work with anyone's point and
polygon objects.

Second of all, if you write code that is doing something nonsensical it
is more likely that you are doing something wrong conceptually and would
prefer a compiler error to remind you that a polygon cannot be within a
point.  The purpose of templates is not to make every line of code the
developer could write compile by breaking down the type safety of C++.
It is desirable to provide conceptual type safety for geometry types
such that you cannot pass point and polygon to the within() function in
the wrong order and get a bug that you have to figure out during
testing.  It is much better to get a compiler error.  It is even better
if the error looks like:

No function within() in point_concept that accepts user_polygon_type.

So that you can easily see from the error itself what your mistake was.

Luke