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

From: gbavestrelli_at_[hidden]
Date: 2000-12-08 13:30:50

--- In boost_at_[hidden], "Gavin Collings" <gcollings_at_s...> wrote:
> --- In boost_at_[hidden], Jeremy Siek <jsiek_at_l...> wrote:
> > 
> 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 (?)
> 

I understand the needs of people wanting Fortran style arrays, but I 
would not love to pay for it with added complexity and abandoning a 
clean layout in my own programs, so if Gavin's suggestion went as far 
as defining two separate arrays, a C style one and a Fortran style 
one, as two distinct and simple classes, I'd be happy. Unless in some 
programs the two would have to work together, then the extra 
generality could be worth the extra complexity. Being fortunate 
enough to having said good-bye to Fortran over 10 years ago, these 
are my feelings. But I know some people are not so "fortunate", so I 
agree a Fortran style Array, one way or another, should be provided. 
And I know there would be a lot of code duplication in the two 
implementations, and that is also not nice. All in all, I think a 
good support for fortran-arrays, including fortran-subarrays, would 
be quite intrusive on the current array, but should be investigated 
well.

Giovanni Bavestrelli