Allow access to subarray from array of cluster elements by array and dot notation

[jlokanis]

When I have an array of clusters and I want to locate the array index where a specific element of the cluster has a certain value, I need to first build an array from the Array of Clusters and then search that to find the Array element I want:

 

It would be nice (and cleaner and likely faster) if I could wire the Array of Clusters into an unbundle by name function and select String[] to get the array of string element to search.

In addition, if the cluster contained nested clusters, I could access them the same way, using the dot notation alrerady supported.  For example, the unbundle would let me select 'cluster1.subcluster2.String[]' to access the subarray of an element.

 

[Sam_Sharp]

I was also about to post this but like others I was beaten to the punch! For BD readability it would be great - especially if you could just wire a cluster array into an standard unbundle by name terminal and it adds the little [] icon to indicate that it's unbundling a cluster array.

+1 from me!

[AristosQueue (NI)]

Rolf: I think the existing subarray would suffice. Clusters are flat types, so an array of clusters is all the elements together. If you have a start point and a stride, you would simply start at the element in the first cluster and then stride the cluster size. There's your subarray.

[X.]

It is already here:

Just paint the For Loop borders the same color as your background, slide the "i" loop index underneath, shrink the Loop and...voila!

[jlokanis]

Yes, but is it faster?  One question I still have is how much time we are wasting looping through the array of clusters.  Or is the compiler smart enough to assemble the output array in the most efficiant manner.

[AristosQueue (NI)]

jlokanis: There is no efficient way to output that array currently. Building that array is an optimization that LV doesn't have. The only efficient strategy is to not build the array but instead to do all operations as operations within the cluster array.

[jlokanis]

Ok.  So this feature would only offer a simplification to the developer and perhaps make reading the code easier.

I had hoped that the cluster array was stored in memory in some manner so that a particular element of the cluster was stored at a consistent offset from one index to the next.  Such that finding that data would mean the output array could be formed by accessing the first index at (cluster address+offset) and each following element would be offset from here by (n*size of single element of the cluster).

But if it is stored as a linked list then its elements could be scattered throughout memory.  In that case the elements of the output array would need to be assembled by walking the linked list and grabbing the data at a consistent offset (assuming again that each element of the cluster was contiguous and identical in its arrangement in memory).

Either way would require a calculation for each element of the output array.  I thought that could be done more efficiently in a language element than the way we express it in 'G'.

But, not knowing what is actually going on with memory storage, this is all speculation.  (And also the reason why I prefer LabVIEW in the first place!)

[AristosQueue (NI)]

 > Ok.  So this feature would only offer a simplification to the developer and perhaps make reading the code easier.

Presumably if we implemented it we would implement it with the higher speed indexing that I proposed in my note to Rolf.

I don't know where the linked list concept came from. A LabVIEW array is contiguous in memory.

[jlokanis]

I missed that.  I went back and read it and now I understand.  Thanks.

So, when will this idea become 'in development'?  

[AristosQueue (NI)]

I don't know. I don't work on that any more.