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

From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2007-01-17 05:52:57

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. 

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