On Wed, Mar 26, 2008 at 4:36 PM, John Femiani <JOHN.FEMIANI@asu.edu> wrote:
IMHO the core need from a point library is the concepts, not the models, because there are so many different well-tuned geometry libraries that exist, and the idea is that boost _algorithms_ work on any "point", rather than that boost have a great point class (those are easy).
I agree, what do you think of this extremely simple starting point? The names definitely need work. template <typename T> struct CompileTimePointConcept { void constraints() { typedef typename at_c<typename T::element_seq, 0>::type x_type; typedef typename at_c<typename T::element_seq, 1>::type y_type; x_type &x = get<0>(value); y_type &y = get<1>(value); } private: T value; }; template <typename T, int N> struct CompileTimePointConcept<T[N]> { void constraints() { T &x = get<0>(value); T &y = get<1>(value); } private: T value[N]; }; template <typename T> struct RuntimeIndexablePointConcept { void constraints() { typedef typename at_c<typename T::element_seq, 0>::type x_type; typedef typename at_c<typename T::element_seq, 1>::type y_type; BOOST_MPL_ASSERT((is_same<x_type, y_type>)); int i = 0; x_type &x = value[i]; y_type &y = value[i + 1]; } private: T value; }; template <typename T, int N> struct RuntimeIndexablePointConcept<T[N]> { void constraints() { int i = 0; T &x = value[i]; T &y = value[i + 1]; } private: T value[N]; }; As you can see, one behaves very much like a tuple, the other like an array. T::element_seq could be an mpl::vector or maybe Fusion could help adapt legacy structs easier (I've not played with Fusion yet). What else would a PointConcept need? "Point" almost feels like a misnomer since it implies much more than most algorithms require... --Michael Fawcett