On 05/25/11 15:44, Larry Evans wrote: [snip]
Maybe one advantage of array_dyn is the ease of rotating the axes. Another may be offset calculation, because with array_dyn, no testing is done for the bool values of general_storage_order::ascending. Instead, an offset and negative strides achieve the same result, AFAICT.
After finding: Reference access(boost::type<Reference>,index idx,TPtr base, const size_type* extents, const index* strides, const index* index_bases) const { BOOST_ASSERT(idx - index_bases[0] >= 0); BOOST_ASSERT(size_type(idx - index_bases[0]) < extents[0]); // return a sub_array<T,NDims-1> proxy object TPtr newbase = base + idx * strides[0]; return Reference(newbase,extents+1,strides+1,index_bases+1); in boost/multi_array/base.hpp, I'm guessing that array_dyn has no advantage in offset calculation since there's no test in that base.hpp code on general_storage_order<>::ascending. However, I'm still not sure how multi_array does it, unless it allows strides to be negative to account for a false ascending value and increments the base value to account for the negative strides, much like array_dyn's: box_domain::init_iter_strides Sorry for the noise about offset calculations. OTOH, there would be no need, in array_dyn, for incrementing all of extents, strides, and index_bases pointers since they're all (well, just extents and strides or really lengths and strides) stored in the same element of an array: box_domain<>::my_length_strides; ; hence, only one increment would be needed. Of course that's a small advantage, and there's probably disadvantages to this array_dyn which I've not thought of yet.