On 11/05/2009 02:25 PM, Rhys Ulerich wrote:

I don't understand why a slice of a multi_array(_ref) isn't simply a multi_array_ref. The current implementation seems to make dealing with slices unnecessarily complicated. The documentation on views is also very thin. Can anyone explain the rationale behind the design?

All I'm aware of is in this article:

@article{garcia2006multiarray,
    title = {{MultiArray: a C++ library for generic programming with arrays}},
    author = {Garcia, R. and Lumsdaine, A.},
    journal = {Software: Practice and Experience},
    year = {2005}
    volume = {35},
    number = {2},
    publisher = {John Wiley \& Sons, Ltd.},
}

which shows some inheritance diagrams that may explain what you're after, but I'm unsure if it will answer your question directly.

Thanks. The article was very helpful. The section "Simulating reference types with classes" explains why it isn't possible to pass a temporary in my original example. I still don't see why an array view is not simply an array ref. I am willing to believe that there might be a good reason, albeit not described in the paper or reference documentation. However, I really think the slicing portion of multi_array is broken.

For the record, I now have a version of my test program that seems to be optimal for my application. The templated solution suggested by Rhys causes problems in my application because the actual function I want to implement is virtual member function. I've worked around the problem by having a separate wrapper function.

Here are my general observations:

1) The multi_array_view type is "hidden" to the extent that it only appears in the "detail" namespace and is largely undocumented.

2) All view/slicing operations return a multi_array_view type.

3) It is easy to get a multi_array_view from a multi_array_ref (et al).

4) It is difficult (impossible?) to get a multi_array_ref from a multi_array_view.

5) Because of (2), (3) and (4), it makes the most sense to write one's interfaces in terms of views if one ever expects to do slicing.

6) Because of (1) and (5), I find the interface to be broken.

7) Minor point: I can avoid the problem of not being able to pass a temporary by accepting the overhead of passing a copy instead of a reference. For my application, that's a win.

I have attached my final working version of the example I originally gave.

--Jim Amundson