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 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.
