Re: A class template for an N-dimensional generic resizable array

From: Gavin Collings (gcollings_at_[hidden])
Date: 2000-12-08 09:58:46

--- In boost_at_[hidden], Jeremy Siek <jsiek_at_l...> wrote:
> 
> I agree that both Fortran order and C order should be supported. The
> reason is that interfacing with F77 is important, and no one wants
> to have to make copies of the entire array merely to change the 
> storage order. Also, some algorithms are more efficient on column-
> major arrays.
> 
> We should probably just steal how Blitz++ handles this issue. It 
> has a "GeneralArrayStorage" class that can be used to specify how 
> the storage is layed out.

There may be another way worth looking at.  As someone has pointed 
out supporting fortran sub-arrays requires abandoning simple 
contiguous data storage for strided slices.  It really depends how 
far we want to go in abandoning one particular, clean, layout in 
pursuit of generality.  Aware of creeping featurism, it might be 
worth looking at a layered approach that utilises the commonality 
between Fortran and C++ array layouts - namely that they map onto 
each other by reversing the order of indices: -

   template <typename T, int DIM> class fortran_array
   {
   public:

      fortran_array( dimensions dims ) : array_( dims.reverse() ) {}

      T element_at( dimensions dims )
      {
         return array_.element_at( dims.reverse() );
      }

      T * raw_data() { return array_.raw_data(); }

   private:

      array<T, DIM>   array_;
   };

If we wanted to support operator[] and sub_array iteration, we'd have 
to go further and define fortran_sub_array.  This would be the place 
to handle striding and slicing.  I assume there would be no 
requirement to access non-contiguous Fortran sub-arrays (?)

Thoughts anyone?

Gavin.