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 18:15:26

Simonson, Lucanus wrote:

> Here I disagree.  First of all, it is an absurd amount of work.

Yes, you have to make an overload per combination for optimality.
However, since most concepts are refinements of polygon, handling 
polygon in polygon should get you support for mostly everything but 
spheres and interpolated stuff, but not in an optimal way.

> Fully
> generic functions cannot be overloaded directly, so you would have to
> use tag dispatching.

While that solution should work fine, I suppose using SFINAE (which 
might be considered "direct overloading") would be best.

> 
> 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.

Overloading over concepts is not much more difficult than overloading 
over types using SFINAE.
There are no best matches with SFINAE however. (there may be ways to 
emulate that, any one knows of any trick?)

> 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.

I don't see how checking if an object is within another, be the 
combination impossible to be true, nonsense.
The type of your object may not be known by your (meta-)program and it 
may need to know whether that information is true.

Would you rather have a trait can_be_within<T1, T2>::value than just 
overloading within to return false?
While it could be useful, requiring to check that before using within is 
quite a big hassle IMO.

> 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++.

You'll have to show how it is type unsound.

> 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.

You are assuming you're never using 'within' from a generic context.
It seemed obvious to me a geometry within boost should be generic, and 
enable people to abstract the type (or meta-type/concept) of objects 
they're dealing with.
If you have to special case everything, then you can't make a generic 
program.

As for 'within', note also that any object may be in a point if you 
consider bounds and if that object is reducible to that same point (a 
polygon with all points being the same or having only one point, a 
sphere with zero radius, etc.).

Which is quite funny if you think about it: the point is actually the 
most refined concept, since it's a polygon, a sphere, a line and 
everything at the same time, even though it's the basic building block.