Variant vs. Binary String

[Eugen Graf]

Binary strings (my choise)

+ are

direct representation of data in memory

takes less memory and so faster

easier to parse partionally (rest of binary string output in unflatten)

mostly used by other programming languages (DLLs & co.)

almost always used by binary protocolls (devices)

- are

not readable by users (not really needed for program inside)

bad for debugging

Variant (and I think XML too)

+ are

better to debug

some properties can be set (like on waveform)

readable by users (can be used to save programm settings)

any more???

- are

what???

Can you tell me in which cases I should better take variant?

Thank you, Eugen

[crelf]

QUOTE (Eugen Graf @ Jun 10 2008, 06:17 PM)

Binary strings...

Do you want us to write the article for you? (really, I'm just kidding!)

[Tomi Maila]

Actually variants are faster as conversion to variant doesn't require memory allocation. Conversion to binary string requires memory allocation as all the items of composite datatype are moved to same sequential block of memory. Furthermore LabVIEW comes with a nice set of utilities to investigate what variants are made of; see vi.lib\Utility\VariantDataType.

[Eugen Graf]

That is not for tutorial (why not?), it's for me.

If my loops communicate using queues, notifiers or user events I can't choose which type of them I want to use. I use currently Binay String Type, but I saw that much people use a cluster with ENUM and VARIANT inside. The enum is the action and variant contains data. I use binary string which contains header and data.

Both is good, has advantages and disadvantages, can you tell me what do you use in this case?

Thank you

[Justin Goeres]

QUOTE (Eugen Graf @ Jun 12 2008, 03:02 PM)

If my loops communicate using queues, notifiers or user events I can't choose which type of them I want to use. I use currently Binay String Type, but I saw that much people use a cluster with ENUM and VARIANT inside. The enum is the action and variant contains data. I use binary string which contains header and data.

As Tomi pointed out, in that situation I would expect Variants to be a fair bit faster than binary strings, because the flattening/unflattening of the string data is slow. However, if you use good encapsulation and style, either approach could be used to generate readable code. If you prefer the binary strings and you're not having issues with speed, I wouldn't worry a whole lot about it.

That having been said, if I got a bunch of code that used binary strings instead of Enum/Variant, I'd scratch my head and wonder why the original developer was still living in the Dark Ages .

[Eugen Graf]

QUOTE (Justin Goeres @ Jun 13 2008, 12:50 AM)

That having been said, if I got a bunch of code that used binary strings instead of Enum/Variant, I'd scratch my head and wonder why the original developer was still living in the Dark Ages .

Why? I use it too, it's good. At all because I can unflatten it partionally and have rest of binary string (> 8.0) to parse it. I can do it more dynamic, whereby variant is more static, because you have to place variant into variant. But you can append one binary string to other binary string.

[Justin Goeres]

QUOTE (Eugen Graf @ Jun 12 2008, 04:29 PM)

Why? I use it too, it's good. At all because I can unflatten it partionally and have rest of binary string (> 8.0) to parse it.

The "Dark Ages" comment was referring to years ago before Variants existed in LabVIEW. Back then, binary strings were much more commonly used than they are today. What I meant was that if I saw a LabVIEW program written today that relied on binary strings to move data around, I would assume that either (A) it was written a long time ago, before Variants, or (B) the developer who wrote it hadn't discovered Variants yet. It wouldn't make the code right or wrong -- it would just make me scratch my head .

QUOTE

I can do it more dynamic, whereby variant is more static, because you have to place variant into variant. But you can append one binary string to other binary string.

Variants are not "more static" than binary strings. I would be willing to wager that anything you're doing with binary strings can be done with Variants.

[Yair]

QUOTE (Justin Goeres @ Jun 13 2008, 06:00 AM)

What I meant was that if I saw a LabVIEW program written today that relied on binary strings to move data around, I would assume that either (A) it was written a long time ago, before Variants, or (B) the developer who wrote it hadn't discovered Variants yet.

Or ( C) the developer was planning on doing something with the binary data (e.g. save to disk, transfer over the network).

[Eugen Graf]

So, I got my first error (comic behaviour) using ENUM_Typedef+Variant Cluster instead of Binary String.

If I define my Queue of this type I have everytime to update my Queue Reference Constant if I add or remove some Items in my ENUM_Typedef.

Of cource I can define my queue as a variant and add there Enum_Typedef and an substituded variant.

But I saw that LV-Programmers use commonly a cluster (not a Variant!) with ENUM and Variant inside.

[Aristos Queue]

QUOTE (Eugen Graf @ Jun 10 2008, 05:17 PM)

Binary strings (my choise)

Hm... my reply would be: "Binary strings are massively slower, require more memory, and are not what you want to use unless you absolutely cannot use variants." Save the binary strings for when you're flattening to a file or for communicating over some network connection.

[Eugen Graf]

QUOTE (Aristos Queue @ Jun 13 2008, 10:05 PM)

Hm... my reply would be: "Binary strings are massively slower, require more memory, and are not what you want to use unless you absolutely cannot use variants." Save the binary strings for when you're flattening to a file or for communicating over some network connection.

Ok, I understand you good. So binary string parsing is slower, but don't understand why. No problem.

Can you tell something about my use case?

If you define a queue of type Cluster with Action-Enum-Typedef and Variant-Data inside them. Than I change my Typedef, but the queue Type will not be automaticaly updated to this "new" type. What can I do to update queue type automaticaly? Is it possible?

Thank you

[Justin Goeres]

QUOTE (Eugen Graf @ Jun 13 2008, 01:13 PM)

If you define a queue of type Cluster with Action-Enum-Typedef and Variant-Data inside them. Than I change my Typedef, but the queue Type will not be automaticaly updated to this "new" type. What can I do to update queue type automaticaly? Is it possible?

If I'm understanding you correctly, you need to make the cluster itself a typedef and it will solve your problem.

So you will have:

Queue Type Cluster.ctl

(typedef) containing

Action-Enum.ctl

(typedef)

Variant

[Eugen Graf]

QUOTE (Justin Goeres @ Jun 13 2008, 10:36 PM)

If I'm understanding you correctly, you need to make the cluster itself a typedef and it will solve your problem.

So you will have:

Queue Type Cluster.ctl

(typedef) containing

Action-Enum.ctl

(typedef)

Variant

Yes, you understand it very good. It would solve almost all my problems but I want to use this Queue-Ref-Constant in SubVIs. So I want to define this as Control (Input) in my SubVIs.

[TobyD]

QUOTE (Eugen Graf @ Jun 13 2008, 01:46 PM)

Yes, you understand it very good. It would solve almost all my problems but I want to use this Queue-Ref-Constant in SubVIs. So I want to define this as Control (Input) in my SubVIs.

I think I understand what you are saying. What Justin said is still your solution. If you save the cluster as a typedef you can use it as a control in SubVIs or as constant on a block diagram and it will propagate any changes automatically anywhere the typedef is used.

[jdunham]

QUOTE (Eugen Graf @ Jun 13 2008, 12:44 PM)

But I saw that LV-Programmers use commonly a cluster (not a Variant!) with ENUM and Variant inside.

If you are frequently using a typdef which contains an enum describing the type of data along with a variant containing the data itself, then you have a prime candidate for using LabVIEW lvclass objects (LabVOOP) instead. With LabVOOP, you can put different data types (different child classes) on the same wire without having to have an enum and lots of case structures whenever the variant data is interpreted. Instead, you drop your code into dynamically dispatched VIs, and at run time, the correct DD VI is called based on the type of data in the wire. This should work very well in combination with the use of queues to pass the data around.

[Eugen Graf]

QUOTE (jdunham @ Jun 13 2008, 11:50 PM)

If you are frequently using a typdef which contains an enum describing the type of data along with a variant containing the data itself, then you have a prime candidate for using LabVIEW lvclass objects (LabVOOP) instead. With LabVOOP, you can put different data types (different child classes) on the same wire without having to have an enum and lots of case structures whenever the variant data is interpreted. Instead, you drop your code into dynamically dispatched VIs, and at run time, the correct DD VI is called based on the type of data in the wire. This should work very well in combination with the use of queues to pass the data around.

I am exatly on this pint now:

http://forums.lavag.org/Can-t-find-Type-De...ion-t11161.html

[Yair]

QUOTE (Eugen Graf @ Jun 13 2008, 11:46 PM)

...I want to use this Queue-Ref-Constant in SubVIs.

If I understand correctly, your problem is that the queue reference itself breaks when you change the data type of the queue (even if the data type is a typedef).

This was actually changed in some version of LabVIEW (I'm not sure which, but I'm pretty sure it works correctly in 8.5.1) so that the queue reference is automatically linked to the typedef, but if you want to do this on an earlier version, you can.

To do this, when you first create the queue reference, right click the reference on the front panel and select Show Control. You can then replace the control inside the reference with your typedef and it will then work correctly.