Hello,
Ok, I take your point. I wasn't suggesting that a library not be able to handle more than 3 dimensions. Rather I would suggest that the population of developers who have such requirements must be very small. Considering that generalization on dimension is not trivial for many algorithms, this leads me to the conclusion that the specific algorithms will decide the requirements on their inputs. This is why I chose a traits based interface for the geometry library I've been implementing. There's nothing to stop one from creating a multi-dimensional Cartesian/polar/parametric access traits interface for any algorithm which requires it. So I suppose I agree, the geometry library should not constrain on the number of dimensions. But I don't agree with full agnosticism (to mean agnosticism of coordinate frame as well.) There should be a way to differentiate points further to align with the concrete traits of the dimension they describe.
This sounds reasonable. Certainly there are many 2D/3D algorithms for which there is little point in generalizing to higher dimensions.
But it's not a reason to limit the point concept to 2D/3D. Once you have your points defined dimension-agnosticly (which was really not a big deal compared to some other problems we had when defining our points...), nothing prevents you from writing an algorithm that will only work with a precise dimension because it doesn't make sense for the other ones. Let's take the cross product. Every 3D programmer use it, and it has a sense only in 3D even if it can be generalized with wedge product. Well your cross_product() function will just have to do a BOOST_STATIC_ASSERT to ensure your passing it a 3D point, and will let the rest of the algorithms be dimension agnostic. Bruno