07-24-2012 03:03 PM - last edited on 07-24-2012 04:06 PM by MaryH
Sometimes it's useful to know the default value of a data type for comparison purposes. Some data types have easy default values to check against...'zero' for Numerics, 'false' for Booleans, 'empty string' for String, etc. But what if you have a complex, arbitrary data type...how do you check against the default value? Well, I saw one of my colleagues (a master FPGA programmer) use this trick in his code, and I thought it was novel enough that it deserved a nugget:
The Diagram Disable Structure is normally used to "comment out" code on the diagram. But in this case, we've got a pass-through wire in the Disabled case to define the tunnel output type, but we're enabling the non-pass through case, so we can use the default data type value on the output. As long as you have a wire, you can use this approach to get the default value of the data type of that wire.
I should point out that this trick is particularly useful in FPGA programming when you're testing algorithms with different FXP types...if you were comparing a wire value to a zero constant, and you wanted to avoid type coercion, you would need to go change the data type of the constant every time the FXP type up stream changed...this trick saves you time by eliminating the constant.
07-24-2012 03:38 PM
I am having trouble with this, unless your example is just looking for an empty variant. I used the below example with an error cluster to get the complex variant type, and it only checks to see if the variant is empty. It does work if I keep the strict reference so it is a cluster.
It should alos should be emphasized that this is not the default value of the control (or whatever sourced the wire), but of the data type as you mentioned.
07-24-2012 03:46 PM
Matthew Kelton wrote:
I am having trouble with this, unless your example is just looking for an empty variant.
Oops, my mistake. In my code that I was writing today, it was originally a cluster type, and when I made it more general for the screenshot, it turned into a variant, and it just slipped my mind that this trick wouldn't work with an empty variant. I'll get a moderator to update the image and the text of the post to refer to strict types. Good catch!
07-25-2012 02:50 AM
07-25-2012 05:34 AM
Of course it would, but the conditional compile saves space and compiler effort.
I'm not sure that is true. If you wire a constant to the case selector, LabVIEW since 8.0 will optimize it away completely in the compiled code.
07-25-2012 06:14 AM
That is true, but it also requires the code in al cases of the case structure to be runnable and therefore checks it, contrarily to what happens to the disabled states of the conditiona compile.
07-25-2012 06:18 AM - edited 07-25-2012 06:26 AM
Which in this particular case is just a wire wired straight through, so very little chance of uncompilable code.
Besides at least in older versions of LabVIEW the conditional compile structure still fell over some errors such as Call Library Nodes referencing non existing shared libraries, even in the disabled frames.
07-25-2012 07:43 AM
Nice trick! I note that using a zero-iteration for loop can also provide a default value.
However, a problem with getting a default value in either of these ways is poor readability; it is very unclear that you are using a diagram disable structure (or for loop) in such a strange way. For clarity, it would be better if there was a "Get default value" primative.