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

From: Ronald Garcia (garcia_at_[hidden])
Date: 2007-01-23 17:39:42

On Jan 17, 2007, at 5:52 AM, Markus Werle wrote:

> Ronald Garcia <garcia <at> cs.indiana.edu> 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  
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.

> 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  
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