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

From: Ronald Garcia (rgarcia4_at_[hidden])
Date: 2000-12-08 14:29:02

>>>>> "gbavestrelli" == gbavestrelli  <gbavestrelli_at_[hidden]> writes:

    gbavestrelli> --- In boost_at_[hidden], "Gavin Collings"
    gbavestrelli> <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: -
    >> 

    gbavestrelli> I understand the needs of people wanting Fortran
    gbavestrelli> style arrays, but I would not love to pay for it
    gbavestrelli> with added complexity and abandoning a clean layout
    gbavestrelli> in my own programs, so if Gavin's suggestion went as
    gbavestrelli> far as defining two separate arrays, a C style one
    gbavestrelli> and a Fortran style one, as two distinct and simple
    gbavestrelli> classes, I'd be happy. Unless in some programs the
    gbavestrelli> two would have to work together, then the extra
    gbavestrelli> generality could be worth the extra complexity.

At certain times it is necessary to work with both "C" style and
"Fortran" style arrays, especially when interfacing with fortran which
(IMHO) is unfortunately necessary at times.  I think that given the
right abstractions, code to support a fortran view of arrays can also
support arbitrary dimension permutations without greatly affecting the
complexity of the code. 

Since not everyone is going to need altered views of arrays, simple
abstractions that provide enough hooks to implement an altered view
as an extension of the base library would suffice and provide great
flexibility at what should be a minimal cost in complexity. This
mechanism could also be a way of providing a flattened view of arrays
if the standard iterators iterate across N-1 dimensional subarrays,
which I think is the way to go.

ron