Re: [boost] [rfc] A light weight statically typed matrix template class (again?)

From: Larry Evans (cppljevans_at_[hidden])
Date: 2007-12-06 19:40:57

On 12/06/07 16:07, Andreas Harnack wrote:
[snip]
> Jens Seidel schrieb:
[snip]
>> Nearly always the dimensions are variables, there are only a few rare
>> cases where you know these before. So how about making N and M variables
>> and providing one or two good memory allocators?
>>
>>>          T* data() { return &**m; }
>> Why not &m[0][0]?
> 
> Just a matter of taste, I guess. Actually I'm not even sure yet 
> that it's wise to use a two dimensional array at all. T m[M*N] 
> would work equally well and since there's no interface yet that 
> relies on that structure, the latter might even be the simpler 
> approach. The two-dimensional array just felt to be more 
> 'natural' for a matrix. (whatever that means :-) )
I think n-dimension would be pretty easy.  Instead of:

template<typename T, unsigned int M, unsigned int N>
class matrix
{
...
};

you could provide:

template<typename Value, typename Shape>
class array_fix_shape
{
...
};

where, using concepts maybe, you could constrain Shape to be some
instance of mpl::vector_c<unsigned,S0,S1,...,Sn>.

Then, the rank of array_fix_size would be Shape::size.
You could calculate of strides using some mpl metafunction on
Shape:

         typedef
       some-mpl-function
       < Shape
       >::type
     strides
     ;

  and then allocate storage as:

      Value
    values
      [ mpl::at_c<strides,Strides::size>::value
      ]
    ;

Then operator[] could be defined as:

     Value&
   operator[](boost::array<unsigned,Shape::size>const& indices)
   {
        return values[some_offset_function_<strides>(indices)];
   }

where some_offset_function simply performs a dot product of the
compile time vector, strides, with the runtime vector, indices.