Ronald Garcia
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. I learned from Herb Sutter (http://www.gotw.ca/gotw/059.htm) that operator= is 'using the "create a temporary and swap" idiom' which is based on the copy consructor and clearly indicates what normal users might expect from operator= (and yes, this behaviour makes sense to me). There have to be very good reasons for not to follow that "convention" for multi_array. Please convince me. As I stated before: the whole STL has a different behaviour. This is one of the rare cases where I agree with its design :-) I do not catch the advantage of m2.resize(boost::extents[m1.shape()[0]][m1.shape()[1]]); m2 = m1; over m2 = m1; At least change the docs: If there are good reasons for an esoteric copy assignment, the docs of multi_array should not claim to be as close to STL as can be. They are not and I felt kind of betrayed when I found out. Also I cannot understand why the interface fails to at least support m2.resize(m1.extents()); and m2.swap(array_type(m1)); Was the lack of swap discussed during peer review?
Besides the fact that I get mad about asserts instead of exceptions (please change this to a way users may choose) why do we have such an odd behaviour here?
I'm afraid that we do not agree about the place for asserts versus exceptions.
Who is "we"?
The assertions in operator=() enforce library preconditions regarding assignment. See the document http:// boost.org/more/error_handling.html under "What about programmer errors?"
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. 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. best regards, Markus