#5664 closed Bugs (fixed)
multi_array's operator() checks for Collection concept but requires RandomAccessCollection
| Reported by: | Owned by: | Ronald Garcia | |
|---|---|---|---|
| Milestone: | To Be Determined | Component: | multi_array | 
| Version: | Boost 1.46.1 | Severity: | Problem | 
| Keywords: | Cc: | 
Description
Hi,
The summary says it all, really. The code that implements operator() looks like this:
  template <typename Reference, typename IndexList, typename TPtr>
  Reference access_element(boost::type<Reference>,
                           const IndexList& indices,
                           TPtr base,
                           const size_type* extents,
                           const index* strides,
                           const index* index_bases) const {
    ignore_unused_variable_warning(index_bases);
    ignore_unused_variable_warning(extents);
#if !defined(NDEBUG) && !defined(BOOST_DISABLE_ASSERTS)
    for (size_type i = 0; i != NumDims; ++i) {
      BOOST_ASSERT(indices[i] - index_bases[i] >= 0);
      BOOST_ASSERT(size_type(indices[i] - index_bases[i]) < extents[i]);
    }
#endif
    index offset = 0;
    for (size_type n = 0; n != NumDims; ++n) 
      offset += indices[n] * strides[n];
    
    return base[offset];
  }
It uses operator[] for the indices, but that operator is not a member of the Collection concept, so an iterator should be used instead.
I also think that requiring an index type to model the Collection concept was a poor choice. size(), empty() and swap() aren't needed to subscript a multi_array. Also, begin() and end() are required to be member functions, which is hard to do when trying to use a type from a library. I think it would be better to require a SinglePassRange, as it solves the above problems.
  Note:
 See   TracTickets
 for help on using tickets.
    
Boost.Range did not exist when MultiArray was written. That being said, I'll look into this further.