Are LabVIEW variants the same, similar or different from traditional pointers?

[skinnedknuckles]

The variant data type in LabVIEW often seems to function like pointers used in some text-based programming languages.  Both seem to provide a means of reading-from and writing-to a region of memory representing an ordered series of data objects having defined types and byte counts.

In your opinion, is this comparision more accurate and helpful or inaccurate and misleading?

Is there another LabVIEW object that more closely mimics the behavior of a pointer?

LabVIEW variant vs. c pointer

[tyk007]

Calling variants equivalent to pointers is very misleading, because you are describing two different concepts in your example. One is how data is accessed, the other is the structure and layout of data (regardless of how it is accessed).

For the former - the closest equivalent for a pointer in LabVIEW is the Data Value Reference.

For the latter - the variant can best be seen as a container type that contains potentially any typed value (along with some other features such as attributes like a dictionary).

[rolfk]

If you absolutely want to compare LabVIEW variants to some C programming concept, the closest would be actually an union. But they are not really the same!

LabVIEW is written in C/C++ and uses internally of course pointers. But the entire LabVIEW interface goes to extremely great lengths to completely hide that fact. Pointers are poison in the realms of a data flow programming language like LabVIEW. (And in fact for pretty much every programming language that tries to enforce safety).

As tyk007 points out, LabVIEW Data Value References are the closest thing you can get to pointers. If you should use them for your little database example is however a very debatable question.

[Yamaeda]

A Variant is an undefined data type, so i'd say it's similar to a Void-value. You'll need to convert it on the fly to get anything useful out of it.

[skinnedknuckles]

I agree with all your comments.

It's not really essential to agree upon a close or exact comparison but these discussions help me understand and apply LabVIEW at a deeper level.

What I have found most helpful about variants is that they enable me to pass very different clusters to a SubVI or a state machine irrespective of the cluster contents.  My test station must support 3 very different devices.  Instead of managing three sets of code, I've been able to manage the tests for all of them in a single state machine by bundling hardware settings and user defined test parameters together and passing them to the state machine as variants.  From the state machine, the variants are passed to more specific SubVIs where the variants are converted  back to clusters, unpacked and processed.  It's helped me avoid those terminal block with a bajillion tiny terminals that are hard to see and use. 

terminal blocks

I guess this all made me think of pointers because if I had to do the same thing in c, I would use pointers.  But maybe there is some other loosely typed reference that could pass multiple unique structures, I just don't know what such a thing is called.

Thanks again for your feedback.

[Gregory]

---

@skinnedknuckles wrote:

What I have found most helpful about variants is that they enable me to pass very different clusters to a SubVI or a state machine irrespective of the cluster contents.  My test station must support 3 very different devices. 

---

I think the better way to handle this would be to create a class for each device.

[JimB.]

---

@skinnedknuckles wrote:

What I have found most helpful about variants is that they enable me to pass very different clusters to a SubVI or a state machine 

---

Or just to another loop...

This absolutely works and in fact is a very common design pattern. Take, for example, the ubiquitous Queued Message Handler template where the message cluster consists of a string and a variant.

However, I would generally agree with Gregory. These practices and templates predate LVOOP. There's nothing wrong with it per se, but I'd opt for classes in most cases now.

[skinnedknuckles]

Thank you all for your valuable input.  I have no doubt that better solutions are available using LVOOP.  I've done lots of OOP in C# and have been playing around with some OOP features in LabVIEW but I'm not yet comfortable enough with it to attempt a major project with OOP in LabVIEW.  Hopefully soon I will be ready to take that step.

[rolfk]

It's not an all or nothing question. I personally have worked in applications that are fully OOP framework based but my main use of LabVIEW classes is still actual drivers for instruments and other random hardware. Not to have a uniform HAL (hardware abstraction layer) but simply to have a convenient way of managing various aspects of a device in a central location (the class wire). And yes if that device comes in variations or is an interface to various devices (such as a frame grabber connecting to various MIPI and parallel camera modules) I tend to use inheritance with an end device (camera) specific implementation and an interface (frame grabber) implementation.

True HAL implementations are a tempting project but I have not seen any really convincing solutions so far. They always start very promising and then soon have to compromise on various aspects of real hardware abstraction. And when the developer thought he found the ultimate solution, someone always finds a device he wants to have added to the HAL framework that simply doesn't fit the current HALs abstraction model. 

[Yamaeda]

---

@skinnedknuckles wrote:

Thank you all for your valuable input.  I have no doubt that better solutions are available using LVOOP.  I've done lots of OOP in C# and have been playing around with some OOP features in LabVIEW but I'm not yet comfortable enough with it to attempt a major project with OOP in LabVIEW.  Hopefully soon I will be ready to take that step.

---

Just a note on that, if coming from the C-family (or most other languages), it'll be strange/unnatural with the ByValue-classes of LV. If you want a reference based design, look at GOOP or G#.