Equivalent to C Defines / sparse enums

[falkpl]

Unfortunatly a enum can not be sparse in labview, but in youe example the enum is also not unique in value, is this intended?  this also would not work since the enumerated type is a pre-compile structure to map words to a value if not unique you could not use this in a case structure, probably the bes use of an enumerated type.  as for the #define the typdef version of the enum is closest to this ind is very common in labview. 

My workaround for sparse enums:

1.  make a typdef enum for use in the program

2.  Make an enum to sparse value function to use when the value of the enumerated type is important.  This is a simple function that takes the typdef enumerated trpe and goes into a case structure, then each case returns a value (usually an int but does not have to be).

One place where this is nice is for error handling:

enumerated type is the type of error (ie motor failed to init, camera grab error) then use the conversion function to make the error code (ie return -5003 to be used in the error cluster).

This is not perfect but does work.

I have wanted a sparse enum far many years, looks like a ring but acts like an enum.  would be very useful!

[chrisger]

An additional feature of #defines is that they are constants. All emulations using rings and enums and clusters and VIs mean that there's code that has to be called. By trying to make the code more elegant and flexible and adjustable the amount of generated code actually increases.

With real #define constants the code would be elegant and flexible and adjustable during edit time but minimal at run time! I can think of some RT targets where this may be an issue.

[Ben]

This thread talks about spares enums in LV.

Do any of those ideas help?

Ben

[tfritz]

Yes, the non-unique values were intended. Actually I don't think this would be a problem. It works in C and it would be even easier to do this in LabView. If I connect an enum with non-unique values to a case structure it would just create a case that has both those names in it. If I try to create two different cases for it it wouldn't run (just as it doesn't run now if I try to create two "True" cases for a boolean case structure). You wouldn't be forced to use enums like this but I don't see why it shouldn't work. But again, I'd be glad if this wasn't called "Enum" anymore but "Define" or something.

One example why I'd like non-unique defines is this: We have a device that uses "Message Types" and "Message Indexes" in its protocol. Depending on the type the same index number might mean different things. But I'd like to have a define for the types and a define for the indexes. Something like this:

typedef enum

{

   MEM=0,

   MEAS=1

} MessageTypes;

typedef enum

{

   MEM_ERASE=0,

   MEM_WRITE=1,

   MEM_READ=2,

   MEAS_START=0,

   MEAS_STOP=1

} MessageIndexes;

About your suggestion: I'd like to have a SINGLE place where I have to change things. If I use an Enum and a VI I have to change two places again. The whole point of using the Enum is to have it in a single location...

But thanks anyway.

Tobias

[tfritz]

No, actually this just creates from C code what somebody here suggested, namely an enum typedef together with a VI that maps it. Still too much overhead for such a simple task.

[Mark_Yedinak]

I agree with you regarding allowing enums to have sparse assignements as well as duplicate labels. This would be a nice feature and it proves very useful when working with protocols. However, in your specific example I would be inclined to separate each set of message indexes into different typedefs. They are after all two different things. A single typedef does make it a bit easier when coding but separate ones truly convey the fact that they have different meanings.

[Ben]

Dumb C Q (what follows and not what preceeds this post)

The Enum in LV can drive a case structure. Could we use an enum in a case in C (did a case exist, was it select, or was that VAX amcro I seem to remeber?)

I only ask because sparse enums would complicate case structures and thinking that may have kept sparse enums out lf LV all of these years. I remebe rthat LV used to be able to use sparse enums just not create them.

Ben 

[Mark_Yedinak]

Enmus in C/C++ are really nothing more than labels for a constant. The compiler replaces these labels in teh code with the constant when the code is compiled. You could use enums in the switch statement in C/C++. From a LV perspective I don't see how sparse enums complicate a case structure. Ultimately it is comparing the input tunnel to a constant. The constant value should be getting placed in the compiled code whenever it is compiled. Also, if you have duplicate values LV could simply include each label in the case structure as mentioned earlier.

[falkpl]

Sparse enums do not complicate the case structure, non unique enums complicate the case structure (not allowed in LabView syntax).  Sparse enums would be great.  The issue has more to do with the fuzzyness between development and compile in Labview.  These are much more clearly seperated in c and traditional text languages.  So a preprocess directive like #def is needed in c++ but would also be nice in LabView.  There are not an easy method of making symbolic constants in labview (such as a typdefed block diagram constant) so the ebst I could do is suggest the workarounds I know of, to emulate what c syntax does.  If symbolic constants could be realized view this could help, just as adding a new type called sparse enum would help the translation from c to Labview.

As for the C select statement I dont think each case uniquness is enforced but hevent coded an C like I used to.

All the work arounds do add additional overhead and should be evaluated for use on a cese by case baisis, I would not use this in my realtime control applicatuions but would use it when I am coding a GUI with a 10-Hz loop timming where a few additional microseconds every once and a while is not missed.