B(tgt{:}) = A(src{:})
is doing -- it took me a while to figure out when I first saw it. Can you confirm that you are happy with the following - src on the left tgt on the right?
I think I understood. Although the statement looks powerful, I think it is a bit of "cheating" because setting up the index vectors tgt and src is done in a loop, by dimension.
I'm not quite sure what you mean by 'cheating' in this context. Do you object to the indirect indexing or the for loop over the dimensions? Please elaborate. What I have in mind for the C++ embodiment of this type of thing is some kind of lazy evaluation of regions of interest (ROIs). Where you can for example 'OR' together dimension regions in a similar manner to constructive solid geometry. For a 2D version of the previous example one would OR together two 1D sub domains along the two different dimensions. This would describe the cross-like structure in the middle. If they were 'AND'ed then it would just be the square section (etc.). A NOT (or equivalently a set difference with the entire structure) would then yield the other part - the disconnected square sections in the corners. Higher dimensions would be identical. The final expression you end up with then only gets concretely evaluated, as and when it's needed, when used to index another expression. So, in this instance, there are no *actual* lists of indices that get calculated. If this can be transformed to a set of contiguous regions in a linear memory view of the arrays then so much the better since the actual copying of the data can be done using something like a low-level memcpy. I don't have sufficiently ninja C++ skills to do this of course!
How would *you* do this, elegantly, in C++? That's a genuine question -- I'm curious because, quite frankly, it's foxed me for ages and I would like to do this in C++! ;-)
I would say this is a typical example that I would solve by recursion. For the case of a nested std::vector, please see attached. Uncomment lines in main for other dimensions, to see that working. Add some more goodies for sizes and stuff and you're done for any arbitrary nesting and/or dimension of data. Not sure if it is the the most elegant solution, though.
Many thanks for 'diving in' to this -- I think it highlights a very different philosophy behind how to approach this problem. Perhaps it is fair to say that the type of (computer) language one uses tends to mould ones approach to given problems. The argument about which is 'simpler' can be left to another day. ;-) -ed ------------------------------------------------ "No more boom and bust." -- Dr. J. G. Brown, 1997