Compare Variant Types

[thutch79]

The variant data type parsing palette is great when you have to deal with passing variants around. However, there is one call that would be super useful. If I have two variants, I'd like to know if they are of the exact same type. The type information only tells you so much. For example, if you have an array in the variant, it will only tell you it's an array, not a double float array, or a waveform array.

I've wrote a version of this that does it, but I'm not sure I cover all the edge cases. NI would be much better suited to ensure it covers all the potential typing possible and can likely make it more efficient than I could. But, I think this implementation solves this issue for most common data types and even some more exotic things that could be in a variant. I would love to see this included in the variant data type parsing palette.

In this example, I'm using it to check an array of variants to filter out ones of type I32.

[AristosQueue (NI)]

I'm going to leave this idea open, but I think the particular solution requested may be too narrow because the problem is broader than stated.

I don't think it has ever been put on the idea exchange, but I know I've talked about this problem with users in the past.

True story: I can count at least five "do these type descriptors match?" functions in LabVIEW's C++ code. Each one has a different definition of equality. I can find 10 additional comparison functions in a quick scan... I'm sure there are more for various custom comparisons.

Sure, some are used commonly, but defining "equal" between types turns out to be a very hard problem. Do you ignore typedefs or not? Depends upon whether you're trying to ask about the control on the panel or just about the data on the wire. Do you care about units? Is an enum equivalent to an integer? Do you just want to know "true/false" equals... or do you really want to know "true/false/coercible"? Do you care about the type inside a refnum or not?

Oh... and the big one... do you care about the names? Sooooo many different ways that names of the top-level type and the elements of clusters/arrays can affect or not affect type equality.

So while we could probably provide five different comparison functions and cover the bulk of use cases, there's probably more of a need for an traversal-style comparison where caller supplies a VI ref to do the comparison at each level.

[thutch79]

Interesting. This is exactly why I posted it here. I suspected this was a rabbit hole to fall down that I didn't fully understand. For the purposes of what I need done, my implementation seems to work. I tried to cover more than I really needed in supporting things like classes and refnums. For me, it's usually about simple data types no more complicated than arrays, clusters and typedefs. Specifically speaking of type defs, I actually handled it two different ways. There's an optional flag on the code I wrote asking if you want it to check that type defs match. It defaults to true. When true, it verifies that the type def paths match. When false, it will disconnect the type defs, then do the normal comparison on the data.

As for what constitutes matching types, for us, what matters is whether or not "variant to data" will fail when we go to convert it back into the type we need. The use case is an array of variants of various types. You need to find the ones that can be used given a specific data type, but you only have that data type in variant form.

[Yamaeda]

If you want exact match including names you can to a Flatten variant and compare the data type arrays. If you only care about compatibility you can use Variant to data with the two types.

[thutch79]

If you compared the flattened variants, wouldn't that be confounded by the value? That wouldn't compare types, the would compare values (with names included).

The use case I'm looking for here is two completely unknown typed variants. The question is, are they the same types. Yes, if you know the type, the simplest thing to do is try to convert the "variant to data". But in this case, I have an array of variants, plus the test variant. I need to compare the test variant to each element in the array of variants to see which have the same type. My example was simplistic for the sake of this post. If I already knew I was looking for an I32, I would just use "variant to data" and check for an error 91.

[AristosQueue (NI)]

Thutch79: Variant To Flattened String function has two outputs ... the string of the data and an array of bytes that represents the type descriptor. Yameda was suggesting comparing the blue output.

[thutch79]

That might indeed do exactly what I need with no fuss. I'll have to challenge this against some different complex data types, but I suspect if that array represents the data types in their entirety, this would work quite nicely.

[wiebe@CARYA]

That blue data does contain the labels...

[Yamaeda]

As said, and pointed out by Wiebe, the Flatten Variant includes the Labels. If you do a Variant to data where you try to convert one to the other, you'll check data compatibility ignoring labels.

[wiebe@CARYA]

---

@thutch79 wrote:

As said, and pointed out by Wiebe, the Flatten Variant includes the Labels. If you do a Variant to data where you try to convert one to the other, you'll check data compatibility ignoring labels.

---

But 'compatible' isn't the same as 'the same'.

This will gladly convert a I32 to I8, and you'll loose data.

I often wanted a function that would warn against "narrowing" of data.

This could be done two ways: 1) actual narrowing happening (no warning if the actual data fits)., 2) potential narrowing.

This is not easy...

[thutch79]

I hadn't really considered the full implications of labels. I was thinking of them more in the context of clusters, which I can afford to be more strict with. But just a numeric with a different label coming back as not the same type wouldn't work.

Also, everyone seems to be missing my point. Variant to Data is NOT a viable option for me, as I need to compare two variants of which I do not know either type. So, I believe the recursive approach I posted is probably still the best option. I may not catch every obscure type possible, but it covers the basics which is what I need. The reason for my post was I was hoping there could be a more native approach, but as everyone has rightfully pointed out, this is not a simple request.