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.