Re: [Boost-users] [multi_array] operator= requires resize - why?

From: Ronald Garcia (garcia_at_[hidden])
Date: 2007-02-08 17:02:04

Hi Markus,

My apologies for the delay in replying.  I have been quite busy.

>
>> Resize was added
>> to the multi_array() long after the library was introduced to boost.
>
> .. because I missed the review ;-)

:)

>> The class is primarily intended to keep the same shape throughout its
>> lifetime,
>
> Isn't this a somewhat artificial usage constraint?
>
Multiarray was meant in particular to be a Generic array library.  In  
particular, all the array data structures were designed to model the  
MultiArray concept, which is specified in the reference  
documentation.  Based on this concept, a programmer can write generic  
algorithms that operate on arrays (are templated on arrays) and so  
long as they adhere to the concept, any of the array types  
(subarrays, multi_array, views, refs, and compliant user-defined  
array types) would be usable with the arrays.  The concept covers  
assignment between arrays, specifically treating them as values:   
assignment between arrays results in a deep copy of the elements, and  
it requires them to have the same shape.  If multi_array's assignment  
had different semantics from the rest of the arrays, then assignment  
would behave very differently generic algorithms depending on whether  
you pass a multi_array or a different function.

>> but resizing is supported primarily to enable default
>> construction of multi_arrays.
>
> So this is water on my mills: since you allow default construction  
> it is
> intuitive beaviour that an assignment following default construction
> will not fail. You require a resize between default construction and
> assignment and I still do not get the advantage.

Yes, I see how this can be confusing.  Taking multi_array alone and  
its support for default construction, the library's behavior seems  
arbitrarily strange.  However, my intent to support generic array  
programming (including assignment between arrays) guided the original  
design, and resizing was added later because it is very useful  
particularly in non-generic contexts.

>
> What Matthias pointed out earlier weighs even more: being forced not
> to rely on compiler generated copy constructor renders multi_array
> useless for many applications I can think of.
I think you mean "compiler generated assignment operator" here (at  
least, that is what Matthias Troyer was pointing to).   Copy  
construction should work fine.   The auto-generated operator= works  
fine, so long as it is understood that assignment can only happen  
between arrays that have the same shape.

>
> Think again:
> - AFAICS ublas assignment semantics differ from yours.

However, MultiArray has been part of boost longer than ublas has.

> - STL assignment semantics differ from yours (!!!!)

That is true.  However, I hope that my discussion of generic arrays  
above might explain why I intentionally differed from the STL in this  
regard.  I did not intend to mislead when I compared this library to  
the STL in the documentation.  The comparison is not exact,  but for  
specific reasons (that at the least are worth documenting.  I  
appreciate that you have pointed out this inconsistency)
>
>>> m2.swap(array_type(m1));
>>>
>>> Was the lack of swap discussed during peer review?
>>
>> Is there something insufficient about using std::swap?
>
> The extra temporary perhaps?
Good point :).

On the whole, there seems to be a tension between my goals for  
genericity (in the sense of generic programming) and the needs of  
boosters that need multi_array to auto-resize for non-generic usage.   
One possible solution (I am interested in feedback), is to add a  
policy option to the multi_array type that would enable resizing  
assignment at compile-time, as in:

multi_array<int,5,with_resizing> A;

In this manner, multi_array by default would provide semantics  
conforming with the MultiArray concept, but for non-generic purposes,  
resizing assignment would be available (and in this particular  
instantiation of multi_array would not be considered a model of  
MultiArray).

Thanks for your thoughtful comments,

ron