LabVIEW
OO Tree Data structure
Solved!
I'm working on a program that uses a tree data structure to store object instances. The way that it occurred to me to do that is to represent the nodes as a class and store the child nodes, which are instances of the same class (WizardAction.lvclass) within the private data for the class:
This is of course not valid: "Illegal default values include: any value of this class itself"
I could work around this essentially by trashing my type safety: I could store the base LabVIEW object class, I could flatten into a string, etc.
Another approach would be to separate the tree structure from the node data (change composition) but to me it makes sense for the nodes to know about their children, rather than having a separate containing object. A cursory Google tells me my approach of each node owning its children is more common in other languages: Data Structures - Creating a Binary Tree in an Object Oriented Language - YouTube but seems illegal in LabVIEW.
Is there a better/preferred way?
I would see 2 different ways:
1. More generic and similar to text-based languages: Use by-reference objects, where each instance keep a list of its neighbors' references.
There are great tools made by the community like OpenGDS or G# to create classes by reference. Both tools use a DVR to a cluster to store "object attributes". The private data of the class itself only contains the DVR, reinterpreted as a U32. This prevents the recursive type inclusion problem that you mentioned. In the object attributes, you can store references of the same class without any problem.
2. More basic, more "LabVIEW": Use native LV classes, but don't store neighbors directly inside the private data. Put all objects in a global list/map. Each object stores a list of indexes/keys corresponding to its neighbors in the global list/map.
@tyk007 wrote:
In the past I have done what you implied - and casted the nested object to a variant - to avoid the compiler error.
The compiler error exists to prevent resolving data recursion (see https://www.ni.com/en-nz/support/documentation/supplemental/06/labview-object-oriented-programming--... ) and implies that this problem does not exist in other languages due to the use of pointers / references. However, my memory tells me I have tried a DVR<object> before and this was also rejected by the compiler, possibly for a similar reason although also possibly due to the special semantics for DVRs of classes. Might be worth retrying though.
Good link to the whitepaper, it explains the issue and a possible resolution: storing a parent class instance instead. It also mentions the tree examples posted to ni.com without linking to any, and I haven't found any. So here's my example, which uses an interface for the parent (LV 2021):
