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