Boost logo

Boost :

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
> to go further and define fortran_sub_array. This would be the
> 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

Giovanni Bavestrelli

Boost list run by bdawes at, gregod at, cpdaniel at, john at