[Boost-users] Slicing interface broken in multi_array (was Re: Slicing multi_array)

Subject: [Boost-users] Slicing interface broken in multi_array (was Re: Slicing multi_array)
From: James Amundson (amundson_at_[hidden])
Date: 2009-11-06 17:52:54

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