With std::vector (and probably all containers?) operator= will potentially reallocate, so I don't understand why boost::multi_array should be special. It's not really a *surprise* reallocation is it?
first of all, linked list (~std::list), ordered trees (~std::set) and queues (~std::queue) don't have this problem at all, and they only need to allocate the storage for the new elements (or something of order 1); and they are designed with that in mind. going back to std::vector: What you say is correct for a dynamic (one dimensional) arrays but std::vector implements a more complex machinery to avoid reallocation in most cases. Something that multi_array doesn't do at all. In general, as std::vector grows (e.g. on push_back), it allocates more space that it needs. This is done automatically each time the vector *has* to grow, for example by duplicating the allocated (reserved) space; or it can be done manually. That is why all these methods are defined for std::vector reserve() capacity() which are different from resize() size() because of this trickery, reallocation in std::vector happens much less ofter than you may think. The price is extra storage (or optionally more manual control of reserved space.) Going back to your example: If assigned and assignee std::vector are of the "same order of size" then reallocation is unlikely, or can be amortized the first assignment.
operator= implies to me that you want to forget what's currently being held and assume a copy of the data that the other object has. Don't get me wrong, I agree with you. I am just pointing at the inconsistency in the design of multi_array but also trying to understand what is the origin of the problem and think of possible ways around them.
Now that you mentionad the example of std::vector. I am wondering whether such manual control of multi_array reserved space is THE solution. something like A.reserve({{shape1,shape2,shape3}}); // or just reserve (shape1*shape2*shape3) can the compromise solution for everyone. This can follow elegantly the design of std::vector at least partially. Ronald? (I would say automatic growing is a bad idea for multi_arrays, but manually reserving space can't hurt). Even for the solution I gave in my previous post I would need something like reserve because resize actually does copies and/or constructs element, and I don't need that because the elements will be overwritten anyway on the assignment. That would be the my first application of reserve. Regards, Alfredo