Hi,
- Your library has a limited scope: 2D orthogonal and 45-degree lines.
(And its name ought to include some indication of that.) I would like to see some exploration of in what way your interface (as opposed to your algorithms) is tied to this domain, i.e. to what extent your interface could be re-used for a more general or differently-focused library. For example, could you have a Point concept that could be common with Barend's library, allowing Federico's spatial indexes to be
used with both? Or would do you require (e.g. for algorithmic efficiency reasons) a point concept that is inherently incompatible?
For me, requiring a point concept that a has an x() and y() member functions is unnecessary and restricts the usefulness of the library. I could obviously make such a requirement, but I would prefer to have adaptor functions such as: coordinate_type point_interface<T>::getX(const T& point); which allows compatibility with anyone's point concept, rather than requiring that everyone have syntactically compatible point concepts. Federico's spatial indexes should be compatible with both libraries already, provided they are conceptually 2D points, regardless of what API the provide or concept they model. Even if I took out the inheritance/casting, I still wouldn't require a specific API on the user type. Shouldn't generic code ideally work with any type that is conceptually a point, rather than only types that model the point concept they set forth?
The point concept of Barend's library doesn't require any x() or y() member functions. The fact that the library proposes 2 predefined point classes, point_xy and point_ll, can be a bit confusing but don't be fooled: they do *not* represent the point concept, they are only 2 classes that satisfy it. The point concept uses accessors of this kind : template <int I> value() const; In the second preview of the library, there was also runtime indexing accessors, but they should disappear to only have compile-time accessors as shown above (I'm currently working on this with Barend). Also, the point concept as currently defined might be replaced by a point_traits class usable the same way as what you propose with your point_interface<T>. It gives something like : point_traits<T>::value<0>(p) to have the first coordinate of a point p. The point concept would then follow the exact definition just given by Phil. Not sure yet this will be done, but it brings a lot of advantages (non-intrusiveness, possibility of using native arrays as points, ...). Regards Bruno