Re: multi_array management

From: rwgk (rwgk_at_[hidden])
Date: 2002-01-09 17:52:28

> Yes providing handle-based copy operations was a design decision I
> considered while writing multi_array. I used deep copy semantics in
> order to keep it in line with the other standard library 
containers. 
> I wonder if it may be possible to provide the semantics you need
> while retaining the spirit of the current standard containers...

I believe, ultimately tools should be designed to be useful,
rather than "standard".
In my practical experience as a "scientific programmer" I find the
following problems with the STL that are becoming increasingly 
annoying
as our system grows (I compiled this list for myself /before/ looking
at multi_array):

std::vector
  always owner of memory
  copy semantics not efficient for numerics
  encapsulation is getting in the way (data only exposed as const T*)
  arbitrary decision for operator< etc. (vector reduction)
std::valarray
  heterogeneous operators are missing
std::complex
  no portable way of viewing std::complex<T> as an array of two T

Given that I find problems like this with the STL, my point is that
that some deviation from the STL paradigms could be very well
justified.

My question about operator+() is just a simple, familiar example. The
more general situation is that a function /creates/ a
multi-dimensional, array, fills it with the results, and returns 
these.
AFAIK, Without handle-based copy semantics this is very cumbersome to
do. You could wrap the entire multi_array in a shared pointer, but 
than
you can no longer use, e.g., operator[]() directly.  IMO this is still
very cumbersome.

> When multi_array is used for non-numerical purposes, a handle-based
> copy would be unintuitive, especially when considering the semantics
> of the other standard library containers.

I have difficulties envisioning uses for multi_array that are not some
kind of numerics (what would the element type be?). It seems to me
that the community served by handle-based copy semantics is much
bigger than the community served by deepcopy semantics.

I would also argue that a handle-based multi_array actually serves
both communities. It is easy to:

  Array A;
  Array B;
  A = B.deepcopy(); // creates a new handle-based temporary and copies
                    // the array-meta information (shape, handle, 
etc.)

or

  Array X::foo() { return this->A.deepcopy(); }

I do not believe that anyone would ever notice the tiny overhead
introduced by the reference counting.

Contrast the need (and frequency of the need!) to spell out "deepcopy"
with the difficulties of returning an instance of your current
multi_array from a function without performing a deep copy.

Overall (apparently like everyone else) I really like the multi_array
interface, but I am deeply concerned that a very important opportunity
is lost if it is accepted into boost with the deepcopy semantics.
My group, for one, would still be left in the rain. It would be
interesting to hear from others who care about this issue.

Ralf