I think having a flat_array_view adapter in boost would be helpful. Something along the lines of https://github.com/m-w-a/sandbox/blob/master/flat_array_view.cc What do the maintainer(s) of Range and others think? Mostafa
On Fri, Jan 03, 2014 at 03:13:26AM -0800, Mostafa wrote:
I think having a flat_array_view adapter in boost would be helpful. Something along the lines of https://github.com/m-w-a/sandbox/blob/master/flat_array_view.cc What do the maintainer(s) of Range and others think?
Your source code seems to be missing a license statement. I believe that for source code to be viable for inclusion in Boost, it should be licensed under the Boost Software License. -- Lars Viklund | zao@acc.umu.se
On Fri, Jan 03, 2014 at 03:13:26AM -0800, Mostafa wrote:
I think having a flat_array_view adapter in boost would be helpful. Something along the lines of https://github.com/m-w-a/sandbox/blob/master/flat_array_view.cc What do the maintainer(s) of Range and others think?
I think that would be useful. Can it be generalized to work for any range of ranges, not just arrays? Regards, Nate
On Fri, 03 Jan 2014 09:28:09 -0800, Nathan Ridge
On Fri, Jan 03, 2014 at 03:13:26AM -0800, Mostafa wrote:
I think having a flat_array_view adapter in boost would be helpful. Something along the lines of https://github.com/m-w-a/sandbox/blob/master/flat_array_view.cc What do the maintainer(s) of Range and others think?
I think that would be useful.
Can it be generalized to work for any range of ranges, not just arrays?
I think so. Though I don't know when I'll have time to make a proof of concept. I have to understand the compile time/run time characteristics of the naive implementation I have in mind (which is one along the lines of what John M. Dlugosz proposed). I haven't even considered the coroutines approach route mentioned by Nat Goodspeed. Additionally, what about ranges of range that collapses to a contiguous chunk of memory? Should/can all use cases be detected (and optimized for)? For example, if the join implementation was used, then a 4x3 multidimensional array doesn't need the intermediate end of range checks since we're dealing with contiguous memory. What about boost:arrayS of boost::array, etc...? Mostafa
On Fri, 03 Jan 2014 04:35:54 -0800, Lars Viklund
On Fri, Jan 03, 2014 at 03:13:26AM -0800, Mostafa wrote:
I think having a flat_array_view adapter in boost would be helpful. Something along the lines of https://github.com/m-w-a/sandbox/blob/master/flat_array_view.cc What do the maintainer(s) of Range and others think?
Your source code seems to be missing a license statement. I believe that for source code to be viable for inclusion in Boost, it should be licensed under the Boost Software License.
Updated.
On 1/3/2014 5:13 AM, Mostafa wrote:
I think having a flat_array_view adapter in boost would be helpful. Something along the lines of https://github.com/m-w-a/sandbox/blob/master/flat_array_view.cc What do the maintainer(s) of Range and others think?
I'd love to see more done with Range. The flattener I think should work with any mult-dim array-like thing; not just primitive arrays, but std::array (nee boost::container::array). If the kind of thing imposes that all the elements have the same size, that makes it easy to random access. But I agree with another poster that it's really a special case of any kind of ragged thing. A bidirectional iterator could handle any shape of recursive ordered containers. (You'd have to use type-erasure techniques to handle different number of levels and/or different composition in different elements. Ah, but strong typing normally means you'll have the same number of dimensions and container type for each dimension, all the way down. Only the use of non-fixed-size containers have to be dealt with; any "this or that" containers would already come with their own iterators.) I think writing that to work for any range of ranges will have side benefits, in making other primitive metafunctions fully general (e.g. remove_extent) I see that for a multi-dim primitive array it is particularly simple to view with different organization of the same number of elements, since they are really flat internally. For such arrays, a more general thing would be a redim facade that acts like a fixed-size container. Flat would be a special case of that, and people would more naturally accept that it's for arrays only. (A fully general flattening of ranges could be done with iterating a recursive 'join')
You can also build a literally recursive flattening iterator with coroutines. ;-) Yes, I always thought that would be a great approach to traversing a tree that is easily done recursively. But, that will give a single-pass iterator. For that you can just implement the recursive
On 1/6/2014 1:11 PM, Nat Goodspeed wrote: traverse that takes a functor to perform on each element, with no need for funny business. More specific than just "using co-routines", there's probably a Generator framework around already.
participants (5)
-
John M. Dlugosz -
Lars Viklund -
Mostafa -
Nat Goodspeed -
Nathan Ridge