LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

what is the advantages/disadvantages of an enum vs strings for state machines

what is the advantages/disadvantages of an enum vs strings for state machines

0 Kudos
Message 1 of 6
(15,678 Views)
The advantage of an enum is that they are a strongly typed value. There are no advantages to using strings. A recent discussion on another thread demonstrates this fact clearly.

The question really gets down to whether you believe that software should be designed, or simply hacked together until you get something that you think works.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 2 of 6
(15,668 Views)

I agree with Mike that enums have a great advantage in their strong typing. You can't make spelling mistakes and if you set up the case structure not to have a default value, you can usually be able to guarantee that you will handle every new value because the code will break when you add it.

 

That said, I don't agree that strings don't have advantages. The main advantage I can think of is if you want to have standard reuse code for handling your state machine (such as error state injection or logging). This isn't possible with enums because each enum will be considered a different data type.

 

Ultimately, I think it comes down to a matter of personal preference. If your state machines are simple and flat, an enum will probably work better. If you have some complexity or you want to have many SMs with reuse VIs, strings might be preferable.


___________________
Try to take over the world!
Message 3 of 6
(15,649 Views)

At times I hate replying to these esoteric questions but,.....

 

A type defed enum restricts acess to the SM to the set of callers that have acess to the enum definition.  That definition us usually contained in the project of the SM  and therefore the caller must have some knowledge of the SM (Its capabilities)  This "overcouples" the callers to the callee but, is usually not a barrier to executing the LabVIEW developers intention since the caller breaks when the type def changes are not applied to the caller.  When applied to the caller they change the caller without high visability (may cause unexpected behavior if cases swap order)

 

Strings, on the other hand, are universal so, changes in the SM being called do not break the caller they mearly cause run-time errors if the case name strings change that require the caller to be modified to call the callee with new correct instructions. 

 

Like I said, pretty esoteric.  With either method the caller needs to be updated if changes are made to the SM.  One breaks at edit or changes unexpectedly, one errors at runtime.  As tst said it comes down to a matter of preference.


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 6
(15,640 Views)

And you're welcome to read this or search for more - http://forums.ni.com/t5/LabVIEW/Why-is-the-Continuous-Measurement-and-Logging-Sample-Project-in/m-p/...


___________________
Try to take over the world!
0 Kudos
Message 5 of 6
(15,623 Views)

Have you tried a object oriented state machine?

 

https://decibel.ni.com/content/docs/DOC-24499

 

Br,

 

/Roger

 

0 Kudos
Message 6 of 6
(15,595 Views)