On 12/10/07 15:31, Andreas Harnack wrote:
Larry Evans schrieb:
On 12/07/07 19:14, Larry Evans wrote:
On 12/07/07 11:05, Larry Evans wrote: [snip] Hi, Andreas.
[snip]
efforts; I'm afraid, however, I don't quite know what you're aiming at. As I understand you want to extend the concept of the matrix as a two dimensional array to that of a multi dimensional array, assuming that they follow the same principles?
Yes.
That sounds interesting, though I'm not sure that's sensible. I'm aiming at simplicity.
I understand, and I agree that this: template < class Value , class Shape
struct array_multi : public mpl::eval_if_c < bool(mpl::size<Shape>::type::value-1)//if rank>1 , mpl::identity //rank>1 < array < array_multi < Value , typename mpl::pop_front < Shape >::type > , mpl::front < Shape >::type::value > > , mpl::identity //rank==1 < array < Value , mpl::front < Shape >::type::value > >
::type { };
is certainly more complex that this: template < typename T , unsigned int M , unsigned int N
class matrix { ... }; however, the array_multi "reuses" array; hence, is less complex *and* more general since it can handle any rank array. Hence, I thought the extra complexity of, let's call it the inheritance spec, would be worth the extra generality. After all, if just simplicity is what you want, then just use boost::array. OTOH, if your particular needs are just for rank 2 arrays, then your matrix is "made to order". OTOH, as soon as someone comes up with a use-case for rank>2, you have to reinvent what's essentially already provided by array_multi. I guess it just depends on whether one thinks the "bit" extra complexity of array_multi is worth the increased generality (I know, that's obvious, but that seems to be the essential reason for the matrix vs. array_multi argument). [snip]
I'm not yet sure how deal with variable sized matrices (or rather whether to deal with them at all). They certainly will be important for some people, but would come at the price to give up compile time size checking.
Doesn't multi_array implement variable size arrays. I see there's: template <typename ValueType, std::size_t NumDims, typename Allocator = std::allocator<ValueType> > class multi_array { ... template <typename ExtentList> explicit multi_array(const ExtentList& sizes, const storage_order_type& store = c_storage_order(), const Allocator& alloc = Allocator()); ... }; on page: http://www.boost.org/libs/multi_array/doc/reference.html#multi_array so I guess it just fixes the rank (the NumDims template parameter). And, BTW, apparently the multi_array authors seem to think that the cost of extra template complexity is worth the gain in generality; otherwise, they wouldn't have bothered with their library. -regards, Larry