
Boost : 
From: Larry Evans (cppljevans_at_[hidden])
Date: 20071206 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 twodimensional array just felt to be more
> 'natural' for a matrix. (whatever that means :) )
I think ndimension 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
somemplfunction
< 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk