Antonio Piccolboni wrote:
As I said in a former message that I am afraid fell through the cracks, sorry if I am repeating myself, I don't think rewriting the whole STL algorithm lib for multi_array is a solution. for_each, accumulate, sort, where do we stop? I recently needed to apply random shuffle, for instance. I think the solution is to define iterators that provide a "flat", element by element view of a multi_array. These iterators would be regular skip iterators that just a have a fancy increment operation that looks at the stride vector to decide by how much to jump when incremented.
I agree that would be the ideal solution, but the multi_array-specific algorithms have one big advantage that kind of iterator: they already exist.
I've been using data() and data()+num_elements for the same purpose, but that breaks for non contiguos storage (that is, not guaranteed to work for views)
That's exactly the issue that these algorithms address. They accept regular multi_arrays, subarrays, and views and handle them all correctly.
I don't think rewriting all the algorithms for multi_array is a viable strategy, nor is in keeping with the idea that data structures and algorithms should be made as ortogonal as reasonably possible. Just my 2c
I agree in theory, but I'm not familiar enough either with the multi_array library or template programming in general to tackle the job of writing the iterator myself. If you or someone else has definite plans to do it, I won't bother with a Wiki page for the algorithms, but if the iterator is likely to remain theoretical for the foreseeable future, it still seems worthwhile to offer a working, though imperfect solution for general use. Jeff Garland described Wiki contributions as "certainly not up to the usual Boost standards, but useful none-the-less." The algorithms don't meet Boost standards for the reasons you described, but I think they conform well to the "useful none-the-less" standard required for the Wiki. Regards, Beth