Ronald Garcia
writes: On Jan 16, 2007, at 9:06 AM, Markus Werle wrote:
IMHO the behaviour of operator= for multi_array is a little bit broken. A lot of preconditions required:
Indeed operator= for multi_array requires the sizes of the multi_arrays to match, hence the assertions. The multi_array type is not meant to automatically resize when assigned to. All resizing is intentionally meant to be explicit. For your application, you will need to resize your array prior to assignment.
Please explain why this is good design. An operator= that has preconditions for the object state which will change through the assignment is somehow unexpected and AFAICS useless. multi_array is primarily designed so that the parts of the state that are checked, in particular the shape and number of dimensions, will not change. Resizing functionality is special for the multi_array class, and is not available for the other array types provided by the
Also I cannot understand why the interface fails to at least support
m2.resize(m1.extents()); This looks like an oversight on my part. I will see about supporting
On Jan 17, 2007, at 5:52 AM, Markus Werle wrote: library (multi_array_ref, views, and subarrays). Resize was added to the multi_array() long after the library was introduced to boost. The class is primarily intended to keep the same shape throughout its lifetime, but resizing is supported primarily to enable default construction of multi_arrays. reshape() is particular to multi_array and multi_array_ref. this. Thanks for pointing it out.
m2.swap(array_type(m1));
Was the lack of swap discussed during peer review?
Is there something insufficient about using std::swap?
I'm afraid that we do not agree about the place for asserts versus exceptions.
Who is "we"?
We = you and I. Sorry for the confusion.
OK, this is another battlefield. Just a comment: Unfortunately it is _NOT_ a programmer's error, but a user's error. I have written a rather elaborate application with a command-line interface similar to matlab based on boost::spirit. So it is the _user_ who defines objects containing arrays of different sizes. It is a matter of QOI that I catch anything that may go wrong and send information about the error and possible reasons to a text output window. So now instead of having a throwing lib (which I'd prefer even for NDEBUG which is another case against assert) I have to duplicate error checks already contained in the library just to make sure not to have any uncaught error path that leads to a crash.
So instead of try-call-catch I have check-then-call which I find odd.
But as I said before: we are on a side track here. Exceptions clearly are a matter of religion and your mileage may vary. This is why I prefer libs where the user can select the behaviour.
Yes, this is a use that I hadn't considered before. Furthermore, at least resizing is not something likely to be present in an inner loop. I am willing to reconsider the use of asserts in light of your explanation above.
The root of my problem with multi_array is the (IMHO) wrong assignment behaviour which I really like to see changed and I'd rather narrow down the discussion to that issue.
I hope that my comments above have provided some insight into the design decisions underlying the library. Cheers, ron