Pointers in Labview

[naganathas]

What is equivalent to"C/C++ Pointers" in Labview programming?

[DFGray · Accepted solution]

The closest thing is a Data Value Reference.  However, you really do not need them very often.  I would encourage you to explore the "data flow" paradigm of LabVIEW in more depth before resorting to DVRs (which are only available in newer versions of LabVIEW, although equivalent data structures can be created in older versions).  Overdependence on DVRs will result in code that is difficult to debug and prone to deadlocks.

What are you trying to accomplish?  With more knowledge, we may be able to give you a better way to do what you want to do in LabVIEW.

[tbob]

If you are wanting to set values for controls or indicators in one vi from a different vi, you can right click on the control/indicator and select Create - Reference.  The reference contains the address location of the data, similar to pointers containing the address of some data space.  Wherever you need to set a value, you need to create a Value property node and wire the reference to it.  Then you can wire the new data to the property node's Value input.  Thus you can pass a reference of a main vi control to a subvi and change the main vi data from a subvi.

[sahil_ni]

The method where you right click on the control/indicator and select Create - Reference cannot be used to create a reference of constants. Whereas a DVR can be used to create a reference for a constant as well.

Also I tried connecting the reference that I created using the first method (Create - Reference) to "Delete data value reference" function and I received a broken arrow. This shows that this method of creating a reference is different from DVR.

So I think that the method where you right click on the control/indicator and select Create - Reference is just an 'identifier' for the corresponding contro/indicator and does not actually points to the memory.

DVR's corresponds to pointers in C/C++.

[tbob]

What makes me think that a control reference contains the address of the data area is the following vi.  The first reference is not tied to any control.  Typcasting the value to a U32 results in the value 0.  The next two references are tied to specific controls.  The typcasted values look like 32 bit memory addresses.  Of course I may be wrong, but that is what it looks like to me.

Also, the following sentence appears on an NI webpage that describes control references.   Notice the words "or pointer".

"With Control References:
Control References are wired directly to the subVI, sending a reference or pointer to the control to the subVI"

The control reference may be an identifier, but somewhere along the line, the identifier must point to the data space in memory.  Maybe it is the address location of where the control's description lies in memory.  The description could be a certain format, like some number of bytes to hold the label, followed by some bytes to hold the caption, some bytes to hold attributes, some bytes to hold the data value, and so on.

   0x9F300076, an address location or just an identifying number?

It would be nice if someone who really knows could shed some light on the subject.

[nathand]

---

@tbob wrote:

It would be nice if someone who really knows could shed some light on the subject.

---

Why would you need to know this?  Best to treat it as an identifier.  What does a memory address "look" like, other than a 32-bit integer?  The class of the control and other information might be encoded into the reference value, and NI can change the meaning of the reference value in any version.

[DFGray]

Neither DVRs or references are pointers in the strict C/C++ sense.  They have a lot of the same functionality, but they are also "safe." If you can crash LabVIEW by using a stale reference, that is a bug.  In C/C++, it is the way the language works.

Unlike pointers, DVRs include a global mutex, so that when code is dereferencing the data in a DVR in one location, code in another location cannot dereference it.  Anything which executes inside the In Place Element structure used to dereference a DVR is atomic with respect to the DVR.  This can cause all sorts of deadlock and performance issues if not used correctly, but is exactly the type of behavior you want in an inherently parallel language like LabVIEW.  Using a stale DVR will just give you an error; it will not crash LabVIEW or the operating system.

References are simply indexes into what is essentially a hash table of the set of that type of item currently being used.  In that respect, they are more like an object than a pointer.  They have methods and properties.  They can be upcast and downcast.  Using a stale reference just gives you an error. &c.

So it is safe to say that DVRs and references have pointer-like properties, but are definitely not simple pointers.

[tbob]

DF:  Thank you so much for that bit of information.  I think it is very helpful to know what goes on behind the scenes, even if I can't change it.  I was wrong about a reference being simply an address to data space.  I don't like being wrong.  Now that I know better, I am relieved.  Stating that a reference is an object because it has methods and properties makes a lot of sense to me.  So be it.