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

From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2007-01-25 04:15:51

Mark Ruzon <mark34 <at> cs.stanford.edu> writes:

> To Ron's credit, the documentation does not say that multi_array models
> Assignable.  

I disagree and this is why I started the thread, since I was really, really
surprised it did not:

<cite from="http://boost.org/libs/multi_array/doc/user.html">
 The interface design is in line with the precedent 
 set by the C++ Standard Library containers.
</cite>

So either we remove that sentence, mention the exceptions or change the code.

> If it did, it would have to obey the semantics listed above for any
> two multi_arrays that have the same template parameters.  
> I am curious to know the source of Ron's loathing, though.

I think this is a performance issue (numerical simulation people tend
to erase any extra overhead, because their code must compete with
braind dead f77 nerd code that had too much time to evolve), 
but as I said in my other post, we can get around that one with a free
unchecked assign function: I found it by now: std::copy. 
If my profiler points me to multi_array::operator= being the 
bottleneck I still can get along with

std::copy(v1.data(), v1.data() + v1.num_elements(), v2.data());

So please, Mr. Garcia, reconsider my proposal.

You write in another post:

> multi_array's operator=() was designed to behave in a manner  
> consistent with the other array objects provided by the library  
> (subarrays, views, multi_array_ref). 

but since multi_array is special in that it is not a view on data,
but a container it is really OK to have different assignment semantics, too.

> The question
> seems to be: are two multi_arrays with the same template parameters the same
> type or not?  Right now the answer is "sometimes" because of assignment.  I
> think everyone would be better served if the answer was either "yes" or "no."
> I will vote "yes" if given a chance, because it will simplify the class 
> instead of making it more complex.  If the answer is "no", 
> the dimensions might as well be set at compile time. 

Good point.

Markus