Michael Fawcett 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).
In my world, structs are tuples and tuples are structs. Duality. The minimum interface, if you guys do not want to fuss around with fusion, is this: 1) a metafunction to get the size of the tuple (dimensions for points). 2) a metafunction to get the element type given an index. 3) a get/at_c function that returns the actual data. That's all. I can provide a non-intrusive adapter for that for Fusion easily for those who want to do more aggressive generic programming on these specialized tuples. Your interface itself need not have any hard dependency on fusion. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net