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