Re: [boost] Preview 2 of a template Geometry Library

From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2008-03-27 16:01:06

On Fri, Mar 28, 2008 at 9:17 AM, Arash Partow <arash_at_[hidden]> 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