That picture is most decidedly incorrect, as you will discover if you put an indicator on both outputs.
The first will have an array of 100 elements, containing 0...99.
The second will have an array of 100 elements, all zeroes except for #99 which contains 99.
Since I have been working with Labview since version 3.1 I am quite aware about the obvious fact. That was the reason I wrote "tried to illustrate" in my post. The problem I was addressing is, and the topic of this thread is that Labview sometimes is not very memory efficient. In the picture in my original posting Labview will allocate two buffers in point A and B. Perhaps in most cases it may also correct. Since the Labview interpreter can't read my minds, or my know intentions. But then working with large data sets, and doing typical while and for loops tasks. The lack of not be able to work on a preallocated memory without creating a new buffer is sometimes annoying.
F. Schubert wrote:
If working with pointers, you can just add the offset to them. I think the offset was counted in Bytes (as is the Length in MoveBlock).
This sounds logical, but I'm passing an array to the dll call (by pointer, but I never see the actual pointer value in LabVIEW). To pass a pointer that doesn't point to the first element I'd first have to get a pointer to the array (to the first element) in LabVIEW so I could add the offset. I think to get the pointer this would be another dll call, right?
Also, if you pass a pointer to the destination array (which will be modified) how do you access the modified array?
I use the MoveBlock to convert Pointers to Arrays and Arrays to Pointers. For Pointers I set up the input as I32.
But I guess this wouldn't help for Wiebes performance challange, as we will need to copy the array (or both arrays) at the beginning to have the pointers and again after the intended copy to have the data back as array.