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