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