On Fri, Mar 28, 2008 at 9:17 AM, Arash Partow <arash@partow.net> wrote:
Michael Fawcett wrote:
I agree, what do you think of this extremely simple starting point? The names definitely need work.
template <typename T> struct CompileTimePointConcept {
}; template <typename T, int N> struct CompileTimePointConcept<T[N]> {
};
template <typename T> struct RuntimeIndexablePointConcept {
}; template <typename T, int N> struct RuntimeIndexablePointConcept<T[N]> { };
Will there be operators for these types? or will they be externally defined?
The operator required for a RuntimeIndexable point is operator[]. For a compile-time model, you must be indexable by boost::get<>() or provide your own get<>() that will be found by ADL.
That CompileTimePointConcept<T[N]> seems quite interesting but how much use can it really be?
dot_product() and cross_product() come to mind...normalize() as well. It is useful for any algorithm where it is known at compile-time which components you will be dealing with.
What else would a PointConcept need? "Point" almost feels like a misnomer since it implies much more than most algorithms require...
The problem is every algorithm has its own set of requirements for what a point must be able to do/provide. Taking the approach mentioned in the DG video from a previous thread (continually simplfying templated inputs into routines) leads me to believe the most general point concept would be any empty class.
I almost agree. Consider a 3 component dot_product() implementation (the N-dimensional case would of course be more complex to do at compile-time): template <typename L, typename R> /*typeof magic here*/ dot_product(const L &lhs, const R &rhs) { using boost::get; return get<0>(lhs) * get<0>(rhs) + get<1>(lhs) * get<1>(rhs) + get<2>(lhs) * get<2>(rhs); } The actual minimal concept required is simply that every element of the sequences is able to be indexed into, is able to be multipled, and that their result is able to be added. In this case, a boost::tuple would fulfill the model, so would a straight array with an appropriate get<> defined, so would boost::array...and with minimal work, so would any legacy point class. So I think I agree that there isn't really a "PointConcept", but as shown here, there are still concepts that the algorithms require. I suspect a lot of the algorithms dealing with points merely require that each element be indexable and also satisfy boost::is_arithmetic. --Michael Fawcett