On 10/5/07, John Femiani <JOHN.FEMIANI@asu.edu> wrote:
On 10/5/07, John Femiani <JOHN.FEMIANI@asu.edu> wrote:
If we want boost to have a point class I think it will really have to be a set of point adapters and point concepts that work for existing types. There are too many points out there that we would have to interact with, both outside of boost and also within boost. For instance it would be nice if algorithms worked with both Boost.Point and the CGAL point.
I suggested something similar to this during a review (either Andy Little's Quan, or Boost.Units, I can't remember). For example, a Boost dot_product could be implemented as such:
// Note: *SomethingDeducedHere* would be some BOOST_TYPEOF magic template <typename LHS, typename RHS> *SomethingDeducedHere* dot_product(const LHS &lhs, const RHS &rhs) { return get<0>(lhs) * get<0>(rhs) + get<1>(lhs) * get<1>(rhs) + get<2>(lhs) * get<2>(rhs); }
Basically, just assume the point type acts like a tuple or Fusion sequence. Then all the algorithms written can be used with any point class (with a little work in some cases).
--Michael Fawcett
Sounds great to me. Can or should we formalize this into a set of concepts specific to points? Coordinate access is only a part of what a point rewuires; There is the tricky relationship between points and vectors (not std::vector!) and homogenous coordinates.
I.e. point+point is undefined, point-point is a vector, etc...
This has been the source of quite a bit of contention in the past. The problem is, there are scientific users and applications where the distinction is highly important, and then there are game developers (and others I'm sure) who frequently mix both for optimization tricks and compatibility with the graphics API. If you can provide the distinction with no run-time overhead, and a no-overhead conversion to and from, I think both parties would sign off on it. --Michael Fawcett