Re: [Boost-users] [multi_array] Why the precondition on assignment?

Subject: Re: [Boost-users] [multi_array] Why the precondition on assignment?
From: alfC (alfredo.correa_at_[hidden])
Date: 2009-02-26 03:32:22

> My vote would definitely
> be for the expected semantics because if the assignment is present in
> the program, then the programmer probably knows what they're doing.
> More importantly, it would avoid the maintenance burden of
> implementing operator= in classes that have multi_array instances as
> members.

I agree, and specially because operator= in particular can not be
redefined in C++ outside the class.
I would honor semantics avobe all but not without some conceptual
redesing first, (I wouldn't know WHAT to redesign though :)) , that
comes with the unavoidable cost of surprise reallocation and a
modification of current behavior of the library. It also poses some
questions, should base indices be copied too? what if base indices are
different? what if storage order is different? is the storage-order
copied?
Or suppose the opposite, that we want to forbid reallocation (and for
simplicity even reshape) then it will turn out that multi_arrays of
different shapes are effectivelly different
"dynamic" types(e.g. an array of 10x10 and an array of 20x20 are
different beasts although both are the same C++ type). I really don't
know how "effective dynamic types" can be formalized in this context
except that we could throw and exception like bad_cast or domain_error
or size_mismatch or something when using arrays of different shapes.

I hope someone goes around this problem in an elegant manner either
with or without modifying the library; but yes then, the design goals
of MultiArray should be stated more clearly in the first place. I
admit that, in the few cases I had to do something about that, I just
checked if I have to resize the destination array before assignment,
but I was never happy with it. My next idea was to encapsulate the
assigment in a function call that creates an object of class
assign_helper that has a reference to the multi_array with an
operator= that does this check and eventual resizes for me, so I can
use it like this:

  smart_assign(A)=B; // takes care of eventual resize. Used instead of
A=B (which may fail), (both A and B are of type multi_array<double, 2>
for example.)

that was my way arround not being able to redefine operator=; but I am
not sure if it is a good idea yet and whether it is a real improvement
over just something like
'smart_assign(A, B);';

Regards,
Alfredo