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

From: Ronald Garcia (rgarcia4_at_[hidden])
Date: 2000-12-11 09:17:26

>>>>> "RR" == Randy Roberts <rroberts_at_[hidden]> writes:
    RR> I think the important thing to realize here, is that us poor
    RR> sm*cks who have to work with legacy F77 code not just need a
    RR> Fortran **view** of an array, we need access to a pointer to
    RR> the contiguous, Fortran-ordered array data.

I agree with this, but I believe that there may be a misunderstanding
of what is meant by "view."  By a fortran view, I am referring to a
multidimensional array that is stored in fortran order in memory, but
accessed from C++ as though it were a C array.  In this manner, data
may be inserted from C++ as usual, while the view abstraction handles
placement of data in memory such that you could pass your data off to
Fortran if need be.  I do this with matrices using the MTL all the
time.  No copies are involved whatsoever.

This does remind me that if access to fortran arrays is necessary, it
should be possible to create a multi-dimensional array and pass
external data to it.  In this case, the C++ multi-array would simply
be a view into already existing data and would not manage the memory
involved with it.  While this shouldn't be the standard way of using
multi-dimensional C++ arrays, it provides a means of easily
interfacing with legacy Fortran/C/C++ code using an elegant interface
for extension.

Another issue which may come to mind with respect to arrays is
modifying the index value, perhaps to index by 1 as Fortran
does. Blitz++ allows this for instance, as well as arbitrary
indexing.  I'm not convinced that this should be a feature in such a
library.  For starters, I don't think users of such a library should
be writing Fortran code in C++.  While it may make a few cases more
convenient during writing, it can lead to a maintenance nightmare
(where does my index start?).  Indexing of that sort can be handled
external to the library.  This issue is different from the issue of
adding a Fortran view in that the fortran view doesn't alter the
interface as seen by the library user (so long as indices are not
changed to start at 1).

ron